Often underestimated by internal technical and defence teams, and frequently over-privileged, App Registrations can enable powerful pivots following a cloud environment compromise.

Among the most exposed services, Microsoft SharePoint stands out. Present on most M365 tenants and often configured permissively, it provides access to company files via SharePoint and to collaborators files through OneDrive.

This article shares several observations from Red Team operations: how a simple App Registration, loosely or closely linked to SharePoint, can offer broad access to your on-premises IT system, and how exploiting this weak link can render your Tiering segmentation merely symbolic for an attacker.

Introduction to App Registrations

In Microsoft Azure, registering an application (App Registration) in Entra ID allows you to create an identity for that application, along with an associated Enterprise Application. The App Registration defines the application (identifiers, keys, permissions), while the Enterprise Application represents its instance within the tenant, where access policies are applied (such as conditional access policies or assigned roles).

An App Registration contains the necessary information to authenticate to Entra ID and obtain access tokens to interact with Microsoft 365 services via APIs like Microsoft Graph. Depending on the permissions granted – delegated (scopes) or application-level (roles) – it can read or modify resources such as emails, files, users, or groups, as long as the Enterprise Application is instantiated in the tenant.

Typically used to register applications designed to automate business processes (user management, SharePoint file cleanup, O365 activity monitoring, etc.), App Registrations represent a largely unmonitored but high-impact surface.

Indeed, the secrets of App Registrations (certificates, client secrets) are often stored insecurely – in code repositories, workstations, or servers. These secrets allow an application to impersonate itself with potentially elevated privileges (as listed in the App Registration), resulting in stealthy persistence across corporate resources.

For an attacker, compromising an App Registration means acquiring an Entra ID application identity with direct access to certain corporate data – without needing to pivot through interactive user accounts or MFA. While security measures around user accounts are increasing (mandatory MFA, conditional access requiring trusted IPs or devices), these protections are often not yet applied to applications.

Connecting as an App Registration

Azure applications can authenticate with Entra ID using application secrets generated in the associated App Registration:

• AppId + App Secret: This authentication method is equivalent to using a username and password and is subject to the same limitations: it is difficult to ensure their protection, as they can easily be stored insecurely, exposed in command histories, etc.

• AppId + Certificate: This method is more secure, as security solutions installed on machines effectively protect installed certificates. However, it is generally less used due to operational constraints, such as the need to install the certificate on each machine that uses the account.

The application’s credentials and secrets allow it to retrieve an OAuth2 access token, enabling authentication and API calls to Microsoft services (Graph, SharePoint, Exchange, etc.) that it is authorized to contact. This connection method is typically hard to detect if access logs are not enabled or monitored.

App Registration permissions

Each App Registration defines the API permissions associated with the registered application. These are described as roles or scopes across various Microsoft services. For example, application permissions may allow:

• Reading or modifying user profiles (User.ReadWrite.All),
• Managing objects in the Entra ID directory (Directory.ReadWrite.All),
• Reading, writing, or deleting files in SharePoint or OneDrive (Files.ReadWrite.All),
• Reading or writing emails across all mailboxes (Mail.ReadWrite),
• Etc.

During audits, it is observed that these permissions are often oversized compared to the actual needs of the applications. As a result, they can provide attackers with a significant privilege escalation vector if compromised.

Moreover, an attacker can identify an application’s permissions through its associated and compromised App Registration by authenticating via the URL https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token :

The access token obtained is in base64 format, and the permissions defined by the App Registration are embedded within it.

Compromise of App Registrations during Red Team operations

In the context of an attack, it is very common for the compromise to occur progressively. Typically, an initial server is compromised, then a second, and so on, until more critical infrastructure components or more privileged users are reached: initial access, privilege escalation, lateral movement, and so forth.

In recent years, the implementation of the Tier model (Tier-0, Tier-1, and Tier-2) within Active Directory infrastructures has become widespread, resulting in increased security for on-premises IT systems. Another factor has also emerged with the development of EDR agents: detection!

Now, in mature environments, it is much more difficult to compromise Tier-0 (domain controllers, PKI, etc.) simply by compromising a Tier-1 server, all without being detected by the Blue Team (the defence team).

However, during several operations across very diverse environments, SharePoint has proven to be a formidable vector for privilege escalation, and in these cases, no detection was reported by the Blue Team.

Several Red Team operation case studies illustrating this point are shared below.

Case 1: Tier-2 Administrator of a domain leading to the compromise of the Active Directory Forest

This case illustrates an operation for an international client whose IT system includes several thousand servers – application and business servers, industrial systems, infrastructure, etc. The compromise of an initial server led to the compromise of Tier-1 and then Tier-2 administrator accounts.

As soon as administrative privileges were obtained on workstations (Tier-2), a targeted collection phase began with the aim of identifying application secrets.

On several workstations belonging to technical users (DevOps teams, Cloud teams, etc.), PowerShell scripts were discovered. Some of these contained credentials linked to App Registrations, including an AppId, an AppSecret, and the Azure tenant ID to which they were associated:

Exploiting these secrets allows the attacker to connect directly to the Microsoft Graph API, using the permissions already granted in the compromised App Registration.

The App Registration identified in this context had extensive application rights over O365, including:

• User.ReadWrite.All: Read and modify all user profiles.
• Directory.Read.All: Read directory data.
• Directory.ReadWrite.All: Read and write directory data.
• Group.ReadWrite.All: Read and write all group information.
• Files.ReadWrite.All: Read and write all files.
• Mail.ReadWrite: Read, write, update and delete emails in user mailboxes.
• Calendars.ReadWrite: Read and write all calendars.
• Contacts.ReadWrite: Read and write all contacts.
• Tasks.ReadWrite: Read and write all tasks.

Among this set of application permissions, the Files.ReadWrite.All right is particularly critical and attractive for an attacker, as it grants full access to all files stored on SharePoint and OneDrive.

Note: These permissions can be “delegated”, in which case they only apply within the context of what the user can do.

A PowerShell script has been developed by the Wavestone Red Team (SharePwned) to perform keyword-based searches on SharePoint and OneDrive and to download the desired files.

Using this script, and by searching for the name of the Active Directory administration forest (e.g., admin.xx.xxxx.net), several files were identified within users’ OneDrive spaces and subsequently downloaded:

These files, stored in the OneDrive spaces of technical users, made it possible to identify the pivot servers used to access the Active Directory administration forest of the information system.

The insecure secrets storage on workstations and in cloud spaces represent a major security vulnerability. However, the lack of security controls and monitoring around this App Registration – linked to significant privileges – constitutes a critical weakness as soon as an associated Enterprise Application is instantiated in the tenant.

In this case, the Tier-2 compromise, followed by read access to files stored in employees’ OneDrive spaces, quickly enabled the identification of secrets and network pivots necessary to compromise the company’s Tier-0 environment.

Case 2: Remote access to the group’s corporate network following the compromise of a subsidiary

This second case describes a Red Team operation targeting a company with numerous subsidiaries whose networks do not communicate with each other.

First, the IT system of one subsidiary was compromised, along with its Azure tenant.

For persistence and further exploration, the Red Team then created an App Registration, adding the Files.Read.All application permission.

By downloading the application’s secrets at creation, it was once again possible to use the tool developed by the Wavestone Red Team to search SharePoint and OneDrive:

By searching for passwords, accounts associated with remote access solutions to the Red Team’s target company were identified. In fact, some members of the Finance teams in the compromised subsidiary had access to the group’s remote desktop solution and stored their passwords in clear text on their OneDrive.

Although MFA was configured for all users of this solution, only notification approval was required – no code was requested. By flooding users with MFA notifications, one eventually approved the authentication, allowing the Red Team operators temporary access to the remote desktop solution.

Finally, by accessing the Finance application hosted on a Windows virtual machine, access to the group’s internal network was obtained.

Thus, starting from the compromise of a subsidiary with no direct interconnection to the group network, the use of App Registrations once again enabled the discovery of secrets and a pivot into the group’s IT system.

Case 3: Compromise of the EDR deployed on Domain Controller via the CICD pipeline

The compromise of the client’s CICD environment (hosted on AWS) led to the compromise of their GitLab server. With root access to the GitLab server, it was possible to access its database and the secrets stored within. Although these secrets were encrypted, they could be decrypted via the GitLab Rails console.

Among these secrets, Azure clientID and clientSecret for an App Registration were recovered. These credentials allowed access to Azure under the identity of the associated application – in this case, the GitLab application.

On the client’s tenant, the GitLab application had a contributor role on the resources of an Azure subscription. This meant it could manage access to resources and read their contents.

Among the accessible resources, secrets were stored (and readable) in an Azure Key Vault. In particular, clientId and clientSecret values were present:

A new Azure application, named xxxxx-NettoyageSharePoint, was thus obtained. This application had the necessary permissions to read the entirety of SharePoint and OneDrive.

Using an early version of the SharePwned tool, a search for secrets was carried out within employees’ OneDrive spaces. Insecurely stored secrets were discovered in configuration files for administration tools such as mRemoteNg. By default, these configuration files typically contain passwords encrypted with a known public key. As a result, it is possible to decrypt them and obtain users’ passwords in clear text:

The account retrieved here had administrative privileges on the company’s IAM application.

After multiple searches of documentation on SharePoint – still using the SharePwned tool to target the searches – the Red Team was able to understand the SOC team’s intervention methods on the Information System, the vaults where their secrets were stored, and the permissions required to access them.

Then, using the IAM administrator account recovered from OneDrive, an attack was carried out based on the SOC’s intervention procedures, resulting in the complete compromise of the client’s on-premise Information System.

In this scenario as well, targeted searches on SharePoint and OneDrive enabled the retrieval of highly valuable technical information for an attacker, including the EDR agent deployed on the domain controllers, the secrets required for its use, and the permissions needed to access it.

Beyond the passwords recovered (whether encrypted or not) in all the previously described scenarios, SharePoint and OneDrive represent a gateway to knowledge of the Information System for the attacker. When the attacker wishes to remain discreet, they must closely mimic the company’s legitimate business and administrative workflows. The prerequisite for this is first to know them, then to understand and replicate them.

Protect and detect malicious use of App Registrations

As previously mentioned, SharePoint and OneDrive have enabled the retrieval of sensitive and compromising secrets for client information systems. It is therefore essential to raise employee awareness about secure secret storage and to provide them with the necessary tools for this purpose.

Nevertheless, it is important to implement processes and security measures for these applications to ensure compliance with the principles of least privilege and defence in depth. Below are recommendations to apply to these App Registrations.

Regular review and principle of least privilege

It is important to inventory applications with permissions on SharePoint and restrict these applications to the bare minimum. The relevant permissions are:

• Sites.Read.All;
• Sites.ReadWrite.All;
• Sites.FullControl;
• Files.Read.All;
• Files.ReadWrite.All.

As with privileged users and groups, a regular review of these App Registrations is necessary.

Management and monitoring of secrets

To prevent App Secrets from being stored insecurely (in scripts, documentation, emails, etc.), it is recommended to favour the use of connection certificates.

In general, connection secrets should be subject to regular and automated renewal.

Creating an App Registration automatically generates an Enterprise Application. When this is granted read permissions on SharePoint, consent from a Global Administrator is required. As a result, it is not trivial for an attacker to create such privileged applications, and adding a secret to an existing privileged application is often preferred by attackers.

It is therefore important to monitor the creation of new connection secrets on privileged applications.

Reduce the attack surface

Finally, it is recommended to limit the usage capabilities of these applications. This may involve restrictions on source IP addresses or on the time windows during which the application can be used.

Note: It is not always necessary to apply these measures in a “blocking” mode. In fact, detection without blocking can already allow the Blue Team to become aware of an attack and begin their response.

Cet article SharePoint & App Registrations: A Vector for IT System Compromise and Red Team Feedback est apparu en premier sur RiskInsight.

Our product vision: a solution with multiple functionalities

Description

An OT probe is a piece of equipment, virtual or physical, connected to the information system (IS) in order to map and monitor it. It consists of sensors distributed in the network to collect data and central equipment to correlate this data.

A probe is characterised by:

• Its operating mode,
• The positioning of its components,
• Its attack detection methods,
• Its bundle of features.

The illustration below provides more details on each of these items:

Figure 1: Main characteristics of an OT probe

Main functionalities

The functionalities of these OT probes are essential for their users. The illustration below presents a summary of the main functionalities identified:

Figure 2: Main functionalities of an OT probe

More advanced functionalities also appear on some products, such as centralised management of several sites, provision of investigation guides, vulnerability research, etc. According to our observations, the solutions on the market tend towards the same objectives in structural and functional terms. The differences appear rather at the level of the global integration of the probe with the offers of the suppliers.

Our vision of the market: a market in the process of consolidation

Numerous and varied players

Our studies have enabled us to highlight a little over twenty players with diverse profiles on the OT probe market. Over the last five years, some players have appeared, others have disappeared, partnerships have been built and solutions have continued to evolve. All these elements indicate a market that is still in the process of consolidation.

Figure 3: Our market knowledge

Actors with different approaches

As might be expected in such a diverse market, different approaches to the sales model emerge. Some players put more emphasis on their product as such, while others emphasise its integration in their catalogues of services (threat intelligence, SOC, CSIRT…) or complementary products. These approaches naturally influence the contact between the players and their customers: the more the offer emphasises a service, the more the player will seek to have direct contact with his customer.

Our vision of the field: a need for maturity

Our feedback

At least initially, we recommend focusing on critical sites and processes for reasons of time, cost and skill savings. Moreover, in order to offer relevant behavioural detection, the probes require a significant learning time depending on the site on which they are deployed (identification of false positives, false negatives, accumulation of data for learning…). In addition to this time, significant human resources are required during this learning phase, but also later during the daily use of the product (mainly alert management). It will also be important to link the probe management teams and the incident response teams in order to deal with incidents detected by the probe and then confirmed.

Prior to deployment, the positioning of the probes should be studied. Indeed, it will be the key to both a complete mapping and an optimal detection surface. These initial considerations must address important points such as hardware compatibility (switches, for example) with the probes and the architecture of the site (on which the number of probes may depend). In addition to providing a real-time inventory, mapping can help implement or review network segmentation, an essential step in a security project. The qualification phase should also make it possible to check that the chosen probe will understand all the industrial protocols used and to discuss the processing of encrypted flows, if any.

Finally, of course, this type of project cannot be carried out without the integration, from the outset, of the OT teams.

A number of our clients stop at the test phase, but others have started to deploy probes on their critical sites or even on their entire industrial information system. The reasons given for not deploying probes are mainly related to costs, charges and required skills. The sovereignty of a detection probe can also be an important issue in certain environments.

Identified limits

In addition to the above points, technical limitations may also arise. Issues of bandwidth and network overload, induced by the collection of logs, can be anticipated. Moreover, an OT probe is by nature limited to network exchanges, its results (detected threats, security level evaluation…) are therefore to be put into perspective in relation to the resources at its disposal.

Finally, the probes ensure detection. On the other hand, the reaction must be carried out by other means, human or technological. More generally, with their many interesting functionalities, the probes are complementary to good security practices such as: the installation of antivirus and firewall, the implementation of a well of logs and adequate collection configurations, the construction of network documentation, the establishment of dedicated SOC and CSIRT teams… All these practices remain in force and will allow the full exploitation of the probes’ capacities.

Figure 4: Our main feedback on the deployment of an OT probe

Conclusion

The probes offer a range of functionalities that meet real needs. Our meetings indicate that the market players continue to take into consideration the needs that have been brought to their attention in order to improve their product. Despite a consolidating market, the players seem to be technically converging towards extremely similar end products. Differences will be played out on ergonomic details, on the approaches adopted by each and on costs.

Our initial feedback shows the importance of the load and the skills required to use a probe. While they may be useful in an immature context, in order to help with system knowledge and the implementation of good network hygiene, they only really reveal their potential once they are fully integrated into the arsenal of detection and incident response teams, which corresponds to a highly mature context. Thus, it would seem to be a higher priority to follow the good practices outlined above in order to gain in maturity and then to consider deploying a probe in a second phase.

1: See https://en.wikipedia.org/wiki/Purdue_Enterprise_Reference_Architecture

2: See https://en.wikipedia.org/wiki/Port_mirroring

3: See https://en.wikipedia.org/wiki/Network_tap

Cet article Detection probes in industrial environments, our vision of the market est apparu en premier sur RiskInsight.

Let us make a detour through a page of history, before plunging into the heart of our subject :

• In the 18th century, James Watt’s steam engine and coal mining changed the way of working. The use of hydraulic machines made the artisan workshops evolve into much more efficient factories: the 1st industrial revolution was in full swing.
• Then, the 2nd industrial revolution known for Taylorism and mass production is based on the use of electricity and oil. The long assembly lines, dear to Charlie Chaplin, replace the hydraulic and steam engines that are now obsolete.
• The development of new information technologies, from 1970 onwards, supporting operators in the most difficult tasks characterizes the 3rd industrial revolution. In particular, it allowed for increased robotization and production of larger batches.

This 4th industrial revolution marks the arrival of new technologies that are increasingly connected, leading to a high level of dependence on information technology.

Industry 4.0 brings together a set of technological advances and technical tools for optimising industrial processes.

Let’s take a concrete example of a use case:

A company needs to accelerate its production rate and to robotise part of its actions to save time. For example, screwing actions. It chooses to use a collaborative robot, also called a « cobot »^[1], capable of carrying out actions simultaneously or on the same workspace as an operator. The operator will be responsible for presenting the parts to be screwed to the cobot.

In addition to reducing turnaround time, the implementation of this binomial makes it possible to increase the quality of the finished product.

Industry 4.0 use cases increase the cyber risk to business processes. There are two reasons for this: the need for new interconnections of industrial systems with the outside world and the increased potential impact in the event of compromise..

What are the impacts for cybersecurity in this whole story? If we continue with this cobot, the screwing, initially done manually by an operator, is now made easier by the use of the cobot. The cobot has to be connected to receive orders and be updated.

• The manual operation is replaced by a computerised operation that is now exposed to a cyber attack

On a conventional robot, a “safety cage” is present to prevent intrusion by an operator during the operation of the machine tool. On a cobot, as there is collaboration with the operator, this protection does not exist. An impact in case of contact between the cobot’s screwdriver and the operator’s hand would be particularly serious for the operator !

• The introduction of new technologies can increase the severity of a cyber attack

This is not the only consequence of unsafe use of such technology :

• Changing a value in the cobot regarding the screwing torque can lead to a quality defect in case of incorrect tightening ;
• Greater importance of assisted operations means that in the event of a failure, the impact on production will be greater… which will quickly lead to a financial impact.

Let’s sum up a little simplistically :

The question now is how to deal with these risks, without blocking the legitimate demands of operational staff. Spoiler: no, refusing the project is not the solution!

The teams responsible for cybersecurity can anticipate the needs for the implementation of 4.0 technologies by drawing up adapted reflex sheets

From a technical point of view, we can group the advances linked to Industry 4.0 around a few major themes: augmented reality, connected objects, additive manufacturing, etc. Upstream of projects and with a few well-informed industry players around the table, it is possible to anticipate potential demands.

The objective for the cyber security team will then be to draw up a profile of typical use cases, deduce the potential risks and begin to identify appropriate security measures to respond to them. It is also an opportunity to propose “Industry 4.0” checklists to raise awareness upstream of projects.

Concretely, here is an example of a typical reflex card applied to our cobot seen previously :

By preparing upstream, cybersecurity teams are more relevant and effective when a new project is about to start.

Ready to embark on a “4.0” project? This is the ideal opportunity to support the industry in the transformation of its factory by offering adapted cyber security services.

The advantage of “Industry 4.0” projects lies in their ability to make in-depth changes to the foundations, sometimes a little dusty, of systems and networks already installed in the factory.

Does a conveyor project need to exchange information with the outside world? This is an opportunity to propose a secure file exchange server in your industrial DMZ (if you don’t have one, this is also a good time to think about it). Does an augmented reality system need a more stable wireless connection? This is the time to start thinking about strengthening the control of the devices that can be connected to it…

At the risk of repeating the obvious here, the ideal is to arrive upstream of the projects, through a constructive approach, rather than through a 100-page ISSP and guides to standards and technical rules that are not adapted to the cases of use presented.

For the risk analysis of an “Industry 4.0” project, the EBIOS RM risk analysis method facilitates exchanges by sharing strategic scenarios that can be understood by the business

Once discussions have begun on a concrete project, it is useful to carry out a risk analysis to support the discussions. Its depth and method will depend on the size and risks of the project.

This analysis will make it possible to refine the objectives we wish to protect, take a step back from the existing ecosystem and define the most convincing attack scenarios.

Here are some examples of frequently found scenarios :

• Logical sabotage for financial purposes (long version of the Ransomware scenario): A targeted or non-targeted attack, making equipment unavailable for financial gain.
• Stopping/Slowing down production: Targeted sabotage to gain a competitive advantage, revenge by ideology or just by defiance can be carried out by a malicious competitor, an avenger, a terrorist, an activist or even a thrill-seeking amateur. Also be careful not to forget the errors of manipulation !
• The alteration of the quality of the part produced: rather sophisticated and targeted sabotage impacting the quality of the products to discredit the company or simply create damage.

The conclusion of the risk analysis will make it possible to precisely define the cybersecurity measures to be put in place and the associated residual risks.

To move away from the “fortified castle” model, i.e. to focus on the isolation of its industrial IS and perimeter security, and to propose adapted security measures: finer detection, encryption, MCS … in a way, it’s time to move on to “4.0” measures

Our feedback shows that the definition of an action plan is a balancing act in these “4.0” projects. Indeed, by applying an overly restrictive safety model, based on IEC 62443-3-3 type zones and ducts, we run the risk of misunderstanding between the stakeholders. In fact, not all business solutions are compatible or mature, and many have not yet integrated the standards we would like to see applied.

So what to do? One way might be to propose appropriate security measures, “4.0” measures (for the industrial environment in any case) that have already proved their worth in other environments:

• To prevent a threat from spreading, one shall strengthen detection resources, especially the flows from and to industrial IS. This is the time to take advantage of this opportunity to dock with the Group SOC if it has not already done so.

• To ensure the integrity and traceability of transmitted/received data, encryption and authentication can be implemented. Do you already have a Group PKI? Why not think about extending it to industrial perimeters.

• It is also the right time to strengthen its OCM / SCM process. Is the solution connected with the outside? No more excuses for not installing an antivirus, updating it, installing security patches for your favourite OS, etc. This point should be anticipated prior to purchasing the solution, rather than once the product has already been installed!

• Finally the solution is critical for the business? A cyber-resilience component must be anticipated so that the solution can be quickly rebuilt and restarted in the event of an attack.

As we have just seen, there is no shortage of solutions, but they require adapted support from the cybersecurity teams and going beyond theoretical models. So, let’s take advantage of these “4.0” projects to make our industrial cyber security models evolve without a priori!

[1] https://commons.wikimedia.org/wiki/File:Cobot.jpg license CC : https://creativecommons.org/licenses/by-sa/4.0/deed.en

Cet article Industrial Cybersecurity in the Age of Industry 4.0 : how can we secure these new use cases and support business projects? est apparu en premier sur RiskInsight.

In the past year, I had the chance to work with different organisations in their Cloud transformation, and each of them has provided our team of Wavestone consultants with insights and key lessons on what Cloud-based detection systems can and cannot bring to an organisation.

For this article, bear in mind that we will consider any change of configuration leading to a degradation of the security level as an incident. While it does not perhaps fit the exact, usual definition of a security incident, misconfiguration of a Public Cloud service (where resources and data can be directly accessible through the internet) is too serious of an issue to not raise an immediate alert for the security of the information system.

Embrace the quick wins

When using Public Cloud from the main providers (Amazon Web Services, Microsoft Azure and Google Cloud Platform), it is fairly easy to turn on the native detection features and kickstart a basic, yet effective detection capability. Most platforms will provide a central security platform that enables you to detect misconfiguration in the infrastructure you have deployed, score your compliance level against a given standard and raise some alerts when the most typical incidents will occur (see further). There is virtually no reason to skip this feature, which is sometimes free to enable (either for trial or permanently).

Additionally, logging is virtually a non-issue in your security roadmap. Cloud providers will typically allow you to stream the logs from both your virtual machines (through agents), your PaaS components (via a handful of clicks, or a couple of parameters in your Infrastructure as Code templates) and the management plane of your subscription (activated from scratch). This enables your security team to swiftly understand the ongoing activity on the platform and start building on the logs to get some alerts. Moreover, some Cloud providers SIEM systems (such as Azure Sentinel) have ready-to-be-plugged connectors for appliances and external data sources which will parse the logs and remove some of the heavy lifting required when bringing the logs home to the SIEM.

Take the opportunity to improve security right away

Once you have learned the basics of the native Cloud detection tools, it is time to build your own expertise to be able to rely on your own tools! You can also leverage third-party solutions such as Cloud Security Posture Management (CSPM) solutions and configure it to cover your needs.

As hinted above, the native features from Cloud Providers offer some basics alerts which can go a long way. With AWS Guard Duty, you can detect compromising of AWS EC2 access tokens or abnormal access to S3 buckets, Azure Security Center will notify you when potentially malicious activity is detected on a virtual machine, or when Azure AD accounts are likely to be taken over… If you need to be quickly capable to detect attacks, there is a way to leverage the native, ready-to-be-used alerts available (although some of them might require the premium license after a free trial).

One of the key perks of Cloud detection is that you can right away act upon them with automatic remediation! For example, misconfigurations are a real source of concern for security teams, as the Terabytes of data leaked through accidentally exposed S3 buckets will testify. So why not reconfigure any bucket exposed, unless it has specifically been set in an “Allow List”? Automation will allow you to detect the exposition pattern, launch a serverless function which will fix the misconfiguration and could even notify the resource owner or the security team.

This can be done for misconfiguration, but also for malicious activity: if you detect an EC2 token being stolen from the metadata of an instance, you can temporarily remove its access rights. If you notice logging is being disabled, re-enable it and lock the responsible user accounts. This will drastically improve your time-to-react to security incidents.

Of course, you still need to work on the overall incident management process: both on how to avoid the misconfiguration of services (through training of developers and controls in the CICD channels if existing) and on how to manage them once they occur (the operating model is tackled further below).

Get closer to business and continuous improvement

Moving to Cloud is usually a time where applications and workloads will have to pass again through a security review to ensure the architecture and design are sound and safe. But it is also an opportunity to make security detection more relevant to the application.

To make it count, my advice would be:

• Go through the process of “Service Enablement” for new services: as moving to the cloud allow business and IT teams to use hundreds of new features and components, it is important to bring together architects and security teams to assess the main risks for each new technology, find countermeasures to limit these risks and start thinking about the alerts that will need to be implemented in the SIEM ;
• Build an alert catalog for each typical risk scenario and component, with the logic of the alert already pre-defined and only the business specifics to be customised. The “time to market” for supervision should also drop, as a good share of the components used for cloud operations is common to most applications (virtual machines, databases, serverless applications and functions, decoupling systems);
• Keep up to date with Cloud-related attacks to understand the latest vulnerabilities/attackers paths, and integrate them in your detection systems.

All these applications specifics should sit on top of transversal alerts covering your core Cloud functions (IAM, networking, landing zones, etc.). To help you build this core-detection capability, you can obviously count on our team, but I should also recommend checking on the ever-growing CloudSec community, which continuously share its expertise through open-source tooling (as this consolidated-view will prove) or on live and online platforms (such as the Cloud Security Forum and its first Fwd:CloudSec conference this year).

Not everything is easy though!

Based on everything written above, it might seem effortless to get a solid cloud detect and react proficiency. However, some challenges remain to be tackled.

The first one to come to mind is pricing. Often suggested as a selling point for Move to Cloud programs, accurately estimating how much your provider will charge you for Cloud detections is not as easy as it sounds. Over the years, many CSP security solutions have moved to component-based pricing for IaaS and transaction-based pricing for PaaS components. Log storage and alerting are sometimes even more complex, as some solutions will charge you based on log transit and aggregation, while some solutions will charge you for the number of assessments against alerts you run. Significant work is required to determine a truthful budget, and not go bankrupt.

The second key attention point is to understand what your provider offers and what it does not offer in terms of detection. While most solutions will claim to solve all your problems at once, it is unfortunately far from true. And for each security use case, there needs to be a call on whether you are fine with the free option if it exists, if the premium one is required, or if your security teams can make it on their own. Realistically, you will need to start with the native option, until your security team is mature enough, cloud-wise, to move to a homemade process.

Additionally, and maybe the most significant aspect, you need to design an operating model that will allow you to work with multiple subscriptions, multiple teams/businesses and possibly multiple Cloud Providers. More and more organisations are parallelising operations by picking different CSPs for different use cases, which leads to increased complexity for security teams – as they need to manage incidents on different platforms, with responsibilities divided between DevOps, SecOps and the on-premise teams. This will be especially difficult as some misconfiguration will lead to immediate security risks, and a choice needs to be made on whether the Ops or Security is expected to act. Without a strong division of duties across all providers and teams, there is a fair chance a small misconfiguration will snowball its way into a major data leak.

Finally, remember that monitoring your Cloud applications in the Cloud can also create risks. Besides vendors lock-in, you can lose all security functions along with your applications if everything sits under the same management plane. If the global administration rights of the SIEM tenant are taken over by an attacker, he or she will have all the liberty to affect the underlying resources (meaning erase logs, disable alerts or remove remediation capabilities). It is worth thinking about it before stacking your SIEM and critical applications under the same roof.

In the end, to sum it up:

• Grab the low hanging fruits: your Cloud Provider will help you collect and consolidate the logs easily. There are virtually no technical barriers to not use the logs anymore. In addition to that, enable the basic security features provided by your CSP to detect the most obvious attacks.
• Grow your cloud maturity together with cloud teams: The Cloud movement has pushed the business and IT teams (SecDevOps) to work closer than ever. Embrace this philosophy by better understanding the business needs in terms of security, customise alerts and automate your response to allow your capability to scale.
• Optimise costs and operating models to excel: Virtualisation has made a lot of technical aspects easier for teams, but processes can be hard to adapt. Make sure to carefully design your detection/incident response operating model to ensure all your applications and Cloud Providers are covered. Finally, think about cost optimisation when it comes to log management!

Cet article How to improve your cyber detection by moving to the Cloud est apparu en premier sur RiskInsight.

La couverture des risques dans la durée

Le durcissement des équipements

En complément d’une architecture et d’un outillage d’administration sécurisés, il convient d’élever le niveau de sécurité de chaque équipement en appliquant un principe de strict nécessaire. Un guide de durcissement générique peut être créé et adapté à chaque technologie identifiée lors de la cartographie du SI Industriel. Celui-ci permet de remédier à une partie des vulnérabilités présentes au niveau des configurations et des systèmes.

L’utilisation de solutions complémentaires peut également apporter un surplus de sécurité :

• Les antivirus connectés au réseau ou non (impliquant une mise à jour manuelle) vont couvrir les postes industriels contre les virus les plus communs ;
• La mise en place de règles strictes sur les pare feux locaux des machines va empêcher les communications, et donc intrusions, sur les ports inutilisés, et filtrer l’origine des flux en fonction des protocoles utilisés, permettant de mieux détecter des tentatives d’attaques ;
• Des solutions de gestion des comptes administrateurs locaux (par exemple LAPS pour Windows) peuvent enfin permettre de gérer les comptes administrateur natifs des postes de manière centralisée et individualisée.

Il arrive cependant qu’il ne soit plus possible de durcir un équipement du fait de sa vétusté, il faut alors travailler avec le Métier sur la gestion de l’obsolescence des équipements, sur leur éventuel remplacement et en dernier recours sur les capacités à les isoler du reste du SI. Des bloqueurs de configuration pourront également permettre, sur des postes vétustes, de restreindre l’installation et l’utilisation de composants à ceux uniquement nécessaire.

Il est important de rappeler que le SI Industriel souffre de certaines vulnérabilités, mais est avant tout l’outil de production du Métier. Le dialogue avec ces équipes est donc primordial à la compréhension de l’utilisation qu’ils en font afin de résoudre ces vulnérabilités en limitant les conséquences au maximum pour le métier.

Le maintien en conditions de sécurité

Lorsque les équipements atteignent le bon niveau de sécurité, il faut prévoir son maintien dans le temps. Différents scénarios de gestion des correctifs de sécurité ou « patchs » peuvent être définis pour répondre également aux besoins du Métier (disponibilité, intégrité) et synchronisés avec la maintenance industrielle :

1. Intégration dans les processus nominaux d’exploitation (par exemple : les processus de qualification / qualité d’une installation peuvent imposer que les équipements soient à jour). La mise à jour et l’administration des équipements tireront ainsi profit des arrêts industriels d’autant plus si une re-certification est nécessaire.

2. Préparation d’un processus de mise à jour « à chaud » en cas de faille de sécurité critique et d’un processus d’isolation préventive d’une ligne de production le temps que le procédé puisse être interrompu ;
3. Identification des équipements redondants ou périphériques sur lesquels une intervention avec simple information des responsables de sites est possible.

Afin de mettre en place ces process de patch, la cartographie réalisée précédemment doit faire apparaître un inventaire précis des équipements devant inclure :

• L’identification des équipements, leur type, localisation et nombre ;
• Les procédés industriels pour lesquels ils sont utilisés et la criticité associée ;
• Le système d’exploitation/lefirmware, les outils et la configuration ainsi que la mention des versions déployées ;
• Les besoins en termes de cybersécurité au regard des procédés supports ;
• La disponibilité de redondance, de mise en tampon des données et de cold spare ;
• La fréquence de patch requise et l’historique de patch.

Le maintien du niveau de sécurité ne se base pas uniquement sur l’application de correctifs de sécurité sur les équipements. Il convient également de :

• Définir le processus de mise à jour des solutions de sécurité installées sur les équipements coupés du réseau ;
• Installer des solutions de nettoyage de média amovibles qui restent très présents sur les sites industriels – certains produits ont l’avantage d’être portables et donc d’analyser le média pendant le déplacement à l’intérieur du site industriel ;
• Assurer la sauvegarde des configurations des équipements et leurs intégrations au DRP afin de garantir une remise en route post-incident qui réponde aux besoins de disponibilité ;
• Mettre en place un suivi de l’IAM[1] Industriel afin d’avoir un contrôle d’accès physique et logique robuste. Cette action permettra aussi d’automatiser de nombreuses actions fastidieuses de revue de comptes parfois encore faites à la main.

La détection des incidents de cyber sécurité

Les mesures citées précédemment permettent de réduire la probabilité d’occurrence des risques et donc d’augmenter la disponibilité des équipements pour le Métier. Il faut néanmoins se préparer au pire et avoir les outils nécessaires à la détection d’un incident pour le remédier au plus vite et garantir un temps d’interruption réduit au maximum.

La mise en place de la détection

La première étape à réaliser est l’activation des fonctions IDPS[2] sur les équipements réseaux afin d’assurer un premier stade de détection et potentiellement de blocage automatique.

Il s’agit ensuite d’assurer la collecte d’informations en déployant un concentrateur sur site. Les logs des équipement réseaux et serveurs pourront ainsi être envoyés aux SIEM[3] existants ou dédiés dans lesquels se feront corrélation et détection. Les SOC[4] et CERT[5] peuvent alors réaliser les opérations d’analyse, de détection et éventuellement de réaction sur incident en se basant sur des scénarios classiques.

L’anticipation de risques spécifiques

Cependant, la détection basée sur des scénarios classiques n’apportera que peu de valeur aux métiers. La prise en compte de l’ensemble des sources (PC, Linux, UNIX…) et la mise en place de sondes dédiées aux SI Industriels capables de s’interfacer avec des systèmes SCADA peut permettre d’améliorer le système de détection. Toutefois, ces solutions peuvent s’avérer coûteuses.

L’élément clé consistera ici à assurer une montée en maturité et en valeur incrémentale et rapide du SOC.

Se préparer à la remédiation

Pour finir, la détection d’un incident ne pourra aboutir à une remédiation efficace que si le Métier est inclus. Tout comme pour les mises à jour d’équipements, il convient donc de revoir les procédures d’arrêt d’urgence avec les utilisateurs du SI Industriel. La formalisation d’un Plan de Réponse à Incident permet de planifier les actions à mener en cas d’incident cyber-industriel.

Des exercices de gestion de crise dédiés au SI Industriel doivent également être menés pour assurer une préparation optimale des équipes et mettre en lumière les éventuels manques.

Une approche progressive et participative garantira le succès de la démarche

La mise en conditions de sécurité d’un SI Industriel est un chantier complexe qui ne peut être faite qu’avec le Métier. Il convient donc de travailler avec lui de manière progressive et participative sur chacun des chantiers suivants :

• Prendre connaissance de son SI Industriel en réalisant une cartographie en priorisant les éléments les plus critiques ;
• Mitiger les risques sur le SI Industriel en mettant en place l’état de l’art de l’architecture réseau sécurisée et définir les processus d’administration – les SI de Sûreté, par leur criticité, devront faire l’objet d’une attention particulière ;
• Atteindre un niveau de sécurité adéquat par le durcissement et le maintien en conditions de sécurité des équipements dans le temps – des discussions pourront notamment avoir lieu avec les fournisseurs et constructeurs d’équipements ;
• Mettre en place les outils nécessaires à la détection d’incident de sécurité, qui peuvent avoir une influence sur la production, et définir les processus de réaction.

Toutes ces actions ne peuvent pas toujours être menées en parallèle. La définition d’une feuille de route claire va permettre la priorisation des différentes actions pour pouvoir maitriser les coûts et maximiser l’apport pour le Métier.

Si ce vaste chantier est souvent initialisé en central, l’enjeu reste de pouvoir embarquer les sites, parfois répartis dans le monde entier, pour assurer une sécurité pérenne dans le temps. Nous observons, en général, une démarche en deux temps :

1. Un programme cybersécurité pluriannuel (souvent 3 ans) pour un budget de 10 à 15 millions d’euros visant à :

• Réaliser l’inventaire des SI Industriels ;
• Élever le niveau de sécurité du parc existant par la mise en place de protections souvent périmétriques et de filtrage ainsi que la remédiation des vulnérabilités les plus critiques – la définition de procédures est ici nécessaire ;
• Faire émerger un premier réseau de coordinateurs cybersécurité locaux ;

2. La création d’une filière cybersécurité industrielle et de la gouvernance associée réunissant :

• Le cadrage des activités clés à piloter par les acteurs locaux ;
• La construction participative d’outils pour aider ce réseau de responsable locaux à opérer les activités de cybersécurité sur le contenu ;
• La construction des moyens de pilotage de la montée en maturité et de gestion du changement (matrices de maturité, outils de modélisation budgétaire par site, définition d’indicateurs de pilotage, services centraux consommables par les sites…).

La mise en place de la gouvernance peut démarrer après le programme et tirer ainsi profit du premier réseau de correspondants sensibilisés à la cybersécurité bâti par le programme.

Une fois construite, il s’agit ensuite de l’animer et de piloter la progression des sites et des systèmes industriels à la fois en termes de niveau de sécurité et de niveau de maturité.

Cette animation réunit en général :

• Un réseau responsables cybersécurité locaux de 0,5 à 2 ETP[6] par site en charge de réaliser les projets, d’implémenter les activités récurrentes de cybersécurité, d’améliorer continuellement la sécurité et de reporter ;
• Une équipe centrale de 3 à 10 ETP pilotant globalement et appuyant les responsables locaux notamment en termes d’expertise.

[1] IAM i.e. Identity and Access Management.

[2] IDPS i.e. Introduction Detection and Prevention Systems.

[3] SIEM i.e. Security Incident and Event Management.

[4] SOC i.e. Security Operation Center.

[5] CERT i.e. Computer Emergency Response Team.

[6] Ces chiffres peuvent varier significativement en fonction de la taille de l’entreprise et du nombre de sites locaux, il s’agit d’une moyenne observée dans de grandes organisations internationales que Wavestone accompagne.

Cet article Saga (3/3) – Retours d’expérience et bonnes pratiques pour protéger et maintenir en condition de sécurité des SI Industriels est apparu en premier sur RiskInsight.

Introduction

Components of Electron 

https://www.wildnettechnologies.com/build-cross-platform-desktop-apps-with-electron/

Principe de l’attaque

• Le dossier « app » qui contient l’application ;
• Le fichier « electron.asar » qui prépare l’environnement Chronium au lancement de l’application.

app.on(‘browser-window-focus‘, function (event, bWindow) { bWindow.webContents.executeJavaScript(“alert(Hello Github !!’);“) })

Démonstration

Conclusion

Cet article BEEMKA – Electron Post-Exploitation When The Land Is Dry est apparu en premier sur RiskInsight.

Le dilemme de l’évolution des dispositifs antifraude : quels leviers pour intégrer ces technologies ?

Faisant écho à ces problématiques, l’écosystème des éditeurs s’est organisé pour proposer des solutions antifraude s’appuyant sur ces technologies. Ainsi éditeurs et start-ups se sont très largement développés, partout dans le monde (plus de 150 fournisseurs ont été recensés au sein du radar « Antifraude » Wavestone). Le besoin de lutte antifraude a en effet par nature une dimension internationale, notamment dans la protection des flux monétaires qui sont rarement limités à un seul pays.

Figure 2 :Exemple du radar des éditeurs antifraude Wavestone (extrait non exhaustif)

Même si la lutte contre la fraude apparait comme un use case de choix pour démontrer le ROI du Machine Learning (réduction du nombre de fraudes, automatisation de la détection…) et au-delà du choix de la stratégie d’outillage de lutte contre la fraude au regard de la maturité du marché, les questions à se poser doivent rester celles d’une solution SI « standard » (exploitation, maintenance, évolutivité…).

Si les coûts d’infrastructures nécessaires à la mise en place d’outils basés sur le Machine Learning et le big data ne sont pas négligeables, ils permettent de créer un environnement favorable à l’exploitation de la richesse des données pour divers usages (maintenance prédictive des serveurs, connaissance client, etc.) en gardant à l’esprit les garde-fous mis en place par le RGPD.

Figure 3 : Où peut-on agir avec le Machine Learning : exemple d’une banque

Une nouvelle cible à atteindre : une approche “sans couture” technologique et métier

Face aux nouveaux enjeux et l’apport des technologies émergentes, une nouvelle stratégie antifraude doit être désormais définie.

La mise en place d’un dispositif de détection globale de confiance qui devra respecter 5 grands principes.

• L’efficience et l’automatisation : il bénéficiera d’une détection à plusieurs critères (moteur de règles et Machine Learning) et d’une efficacité opérationnelle optimisée par l’automatisation de mesures allant de l’augmentation du niveau d’authentification demandé au gel d’un virement.
• L’évolutivité et l’omnicanal : il intègrera plusieurs périmètres dans la détection avec une logique « sans couture » entre le monde cyber et le monde « hors cyber » et sera conçu pour permettre l’intégration de nouvelles données disponibles (ex : données de biométrie comportementale).
• La visibilité et l’exploitabilité : il fournira la visibilité (reporting) et l’explication des résultats de détection, aux équipes antifraude, aux clients et également aux régulateurs.
• La conformité et la sécurisation : il respectera les obligations en matière de détection ainsi que les réglementations (RGPD), et traitera les risques inhérents au Machine Learning (tentatives de poisoning, compréhension par l’attaquant du modèle…).
• La gouvernance transverse cybersécurité et métier : une collaboration étroite des équipes de détection de menaces cyber et métier antifraude, dépassant les silos encore trop présents, permettra une réponse globale avec une vision 360 des menaces et fera le meilleur usage des données disponibles.

Pour bénéficier de tous les atouts apportés par cette nouvelle stratégie de détection, il conviendra également de ne pas négliger les systèmes d’investigation et de réaction.

Une décentralisation partielle de la lutte contre la fraude, impliquant les conseiller bancaires, permettra une plus grande capacité d’investigation. Ayant la connaissance la plus fine de leurs clients, ces derniers représentent un atout dans le processus d’investigation.

De plus, la biométrie comportementale et le machine learning permettent de fournir une meilleure visibilité sur le niveau de confiance qu’on peut accorder à l’utilisateur. Une fois le niveau de confiance défini, il est donc possible d’adapter les niveaux d’authentification demandés en conséquence. Une contribution adaptée et graduée de l’utilisateur permettra ainsi de réduire le nombre d’alertes émises.

La mise en place d’une nouvelle cible antifraude n’est pas seulement pour assurer une réponse adaptée à un changement de contexte mais aussi pour anticiper une vague de fond qui s’amorce aujourd’hui. La détection de fraudes deviendra à l’avenir de plus en plus complexe compte tenu d’une digitalisation qui va continuer à s’accélérer, en particulier sur les moyens de paiement. L’émergence de nouveaux acteurs, comme les Fintechs, et la désintermédiation grandissante des banques vont notamment entraîner un appauvrissement de la donnée disponible. Les dispositifs antifraude sont donc voués à évoluer en profondeur afin de garder et développer leur efficacité.

Cet article Revolution technologique : quelle perspective pour la lutte contre la fraude ? (2/2) est apparu en premier sur RiskInsight.

Les expériences et expérimentations du secteur bancaire, en avance sur ces problématiques, permettent d’envisager les perspectives à venir et fournit donc un prisme d’analyse utile aussi pour les autres secteurs.

Menaces, usages, réglementations : trois évolutions majeures qui impliquent des adaptations des dispositifs antifraude

Les transformations business et technologiques dans l’ensemble des secteurs d’activité font apparaitre des évolutions impactant directement les dispositifs antifraude historiques.

Les menaces évoluent, les pratiques de fraude se sont professionnalisées avec de nouveaux outils et de nouvelles pratiques. Prenons l’exemple du phishing : même sans connaissances informatiques, une cellule de fraudeurs entrainée peut désormais acheter un kit de phishing prêt à l’emploi et met en moyenne seulement trois minutes entre une connexion frauduleuse et une sortie d’argent. Les tentatives de fraude se sont donc démultipliées ces dernières années.

En parallèle, les usages évoluent vers une plus forte digitalisation, parfois dictés directement par des évolutions réglementaires, à la fois à destination des clients ou à destination des collaborateurs. Par exemple la mise en place de l’Instant Payment en France ou de la directive européenne sur les services de paiement 2ème version (DSP2) prévoient des virements instantanés. Ces nouveaux usages accélèrent les transactions financières entre les acteurs entrainant par la même occasion des besoins d’évaluation instantanée des risques de fraude. De plus, cette multiplication des canaux de paiement entraîne une augmentation de la surface d’attaque avec notamment une diversification des malwares bancaires aux applications mobiles ainsi que l’apparition de pratiques d’ingénierie sociale complexes multicanales et appuyées sur une compréhension des processus métier.

La diversification des fraudes, la volumétrie associée et l’augmentation des besoins de traitement instantané rend le traitement manuel presque impossible. La création de règles d’alertes plus restrictives pour minimiser les volumes ferait cependant courir le risque de manquer un grand nombre de fraudes.

Dans ce nouveau paysage, où la fraude devient de plus en plus technologique et peut avoir de multiples origines (clients, donneurs d’ordres, sous-traitants, fournisseurs, administrateurs…), les stratégies de détection doivent évoluer et passer d’une détection réactive des fraudes connues à une détection proactive des menaces encore inconnues.

Les nouvelles technologies, l’avenir de l’antifraude pour faire face à ce nouveau paradigme

L’approche historique de la détection de fraude est fondée principalement sur la définition de règles unitaires générant une alerte en cas de non-respect d’un des critères et sur la corrélation d’événements, consistant à mettre en œuvre des règles métiers plus avancées prenant en compte plusieurs types de données, afin de générer une alerte lorsque apparaissent des indices du déroulement d’un scénario de fraude connu.

Cette approche tout en demeurant efficace pour la détection de fraudes connues, par exemple dans la lutte contre le phishing, n’est plus suffisante pour faire face aux évolutions en cours. Une approche hybride doit être enrichie sur la base des nouvelles technologies présentes sur le marché (intelligence artificielle / Machine Learning, biométrie comportementale…) qui offrent deux grandes perspectives d’enrichissement des dispositifs actuels.

1.  Passer d’une détection de masse à une détection individualisée beaucoup plus fine qui va se concentrer sur les changements de comportement.

Le Machine Learning a la possibilité de créer des profils individuels à chaque client. Ces profils, composés de variables construites à l’aide des données collectées, vont permettre de modéliser le comportement. Ainsi, les algorithmes utilisés vont comparer le profil du client (et donc son habitude) avec un événement donné et, de fait, remonter une anomalie lorsqu’une divergence apparait. A noter que le nombre de variables manipulées peut facilement dépasser plusieurs dizaines, là où des règles statiques n’intègreront que quelques paramètres, permettant ainsi de démultiplier le potentiel de détection ou de réduire le nombre de faux positif.

2. Diversifier les périmètres à couvrir en bénéficiant des économies d’échelle apportées par ces technologies (mutualisation des infrastructures big data, massification des données, automatisation permettant un gain de temps pour les analystes…)

Ces technologies ont la capacité d’intégrer et corréler, grâce à des Data Lake sur lesquels elles s’appuient, des volumétries importantes de données brutes, techniques ou métiers (logs applicatifs, connaissances clients, opérations financières…) et d’apporter un potentiel d’enrichissement par des données extérieures (liste de surveillance, transformation d’adresses IP en localisations physiques…). Pour tirer le maximum de bénéfices des systèmes antifraudes, le Data Lake doit disposer d’un historique de données pertinentes et conformes, à savoir 13 mois pour des personnes physiques et 6 mois pour des personnes morales.

Pour autant ces technologies ne sont pas « magiques », elles nécessitent d’avoir à disposition des données en qualité et en quantité afin de réaliser un important travail préparatoire sur la construction des variables qui portent les capacités de détection des algorithmes. Cette phase de construction nécessite un apport d’expertise à la fois métier mais aussi technologique (datascience, développeurs, etc.).

Figure 1 – les principales méthodes de détection

Le choix des algorithmes n’est également pas à négliger, notamment d’un point de vue de la transparence. En effet, certains outils sont basés sur des algorithmes où les résultats sont difficilement justifiables. Le manque de visibilité sur les critères d’établissement des résultats entraine une remontée d’alertes en « boîte noire » et ne permet pas toujours de justifier les blocages aux clients. Une trop grande opacité peut également avoir des conséquences juridiques, voir être illégale, lorsque ces alertes ont des conséquences directes sur des clients.

Si ce premier article présente quelles sont les technologies d’avenir dans la lutte contre la fraude, un deuxième article viendra détailler comment les intégrer au mieux.

Cet article Revolution technologique : quelle perspective pour la lutte contre la fraude ? (1/2) est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

GitGuardian souligne l’importance de l’expérience de ses cofondateurs ingénieurs, spécialisés en intelligence artificielle dans la conception de leur solution : « Nous utilisons au quotidien les outils de l’open source, et en particulier la plateforme GitHub », qui reste génératrice de risques pour ses utilisateurs. Certains codes source publiés peuvent contenir une clé privée, suffisante pour « s’introduire dans des systèmes d’information d’entreprise, de la petite start-up aux grands groupes du CAC40 », la solution GitGardian a été créée pour « analyser en temps réel l’ensemble du code open source pour détecter les informations sensibles ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Eric Fourier souligne l’interconnexion croissante entre les systèmes bancaires : « cette augmentation de la surface de vulnérabilité attire les hackers et le nombre de cyberattaques augmente tous les ans. Les failles de sécurité que nous détectons exposent régulièrement des données personnelles, pouvant appartenir aux employés de la banque, à ses clients, ou à des tiers. Ces fuites détériorent leurs images et leur font courir un risque légal et stratégique. Ainsi, GitGuardian permet de diminuer ces risques en détectant certaines vulnérabilités au niveau des interfaces entre les systèmes » bancaires.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

GitGuardian met en avant la nature exogène de sa solution face « à l’infrastructure IT dans la mesure où nous analysons des données disponibles publiquement. Il suffit donc de quelques minutes pour l’installer. Nos algorithmes basés sur du Machine Learning nous permettent d’alerter le RSSI et son équipe sécurité d’une vulnérabilité moins de quatre secondes après l’événement, lorsqu’il est encore temps de limiter fortement les dégâts possibles ». Grâce à ce temps de réaction très faible, la solution est la seule sur le marché à fournir un service aussi précis et rapide car « les acteurs traditionnels s’appuient sur l’analyse humaine, qui peut prendre quelques semaines ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

GitGuardian note l’effort croissant des banques pour protéger leurs clients : « elles luttent contre la fraude bancaire avec des solutions de sécurisation des achats sur Internet, de protection contre les faux sites bancaires ou les tentatives d’hameçonnage. Les banques possèdent aussi des solutions standardisées pour la protection de leurs systèmes d’information, telles que les pare-feus ou le chiffrement des données. Cependant, les banques se protègent péniblement contre les erreurs humaines de leurs milliers d’employés et prestataires répartis sur le territoire français et dans le monde entier. GitGuardian colmate ces brèches en temps réel, avant que des dommages soient causés par des acteurs malveillants ».

Comment voyez-vous la banque de demain ? Quelles opportunités pour la cybersécurité dans la banque de demain ?

La principale tendance qui émerge est celle du numérique et de la transparence. GitGuardian l’explique ainsi : « La banque de demain sera une banque entièrement digitalisée et connectée. Les applications liées au secteur bancaire se multiplient, les exigences des clients s’intensifient et les fraudes bancaires s’amplifient. La banque de demain se doit d’être plus ouverte et transparente, comme en témoigne l’engouement qui s’anime autour de la technologie blockchain. Tout cela se traduit nécessairement par la mise en place de programmes de cybersécurité encore plus élaborés pour protéger la transition et assurer la sécurité de millions de personnes ».

Pour en savoir plus : https://www.gitguardian.com/

Cet article L’interview de GITGUARDIAN – Sécuriser les clés privées est apparu en premier sur RiskInsight.

Face à cela, les outils historiques ne semblent pourtant que trop peu adaptés aux nouvelles menaces, de plus en plus volatiles (40% des attaques ne s’appuient sur aucun fichier déposé sur un poste compromis, d’après une étude de l’institut Ponemon pour Barkly). En conséquence, un nouveau type de solution de sécurité est apparu, mêlant efficacité de détection et remédiation adaptative, les Endpoint Detection & Response (EDR).

AUX ORIGINES : LES ANTIVIRUS

A l’heure du trentième anniversaire de la première annonce de neutralisation d’un virus, les antivirus figurent aujourd’hui parmi les solutions les plus utilisées dans la protection des équipements terminaux que sont les serveurs et les postes de travail. Seulement, de nouvelles stratégies de défense viennent aujourd’hui consolider les fortifications de nos systèmes d’information, afin de faire face à un spectre plus large d’attaques et de menaces.

Une réponse toujours nécessaire face aux attaques connues

Que ce soit pour nettoyer un support de stockage USB ou un serveur critique, les antivirus bénéficient d’une réputation d’outils indispensables grâce à leur stratégie, allant de la détection de fichiers à signatures virales connues à la remédiation, ainsi qu’à leur faible taux de faux-positif.

Aujourd’hui largement employés par l’ensemble des acteurs numériques, certains antivirus efficaces permettent un investissement minime face à des conséquences majeures. Pour exemple, les coûts de l’attaque massive Wannacry sont estimés à près d’un milliard de dollars – mais la somme aurait pu être beaucoup plus élevée. En effet, comme l’a démontré le groupe de recherche MRG Effitas, certains antivirus peuvent bloquer les attaques les plus notables émanant de la faille EternalBlue, par détection de signatures au travers du réseau.

Partant de ce constat, certaines solutions antivirales semblent répondre à la majorité des attentes d’une entreprise « connectée », à savoir détecter les menaces les plus massives. Cependant, la recrudescence des attaques ciblées et sur-mesure laisse envisager une banalisation du contournement de ces défenses traditionnelles. Ces attaques peuvent conduire à une intrusion dans les  systèmes d’information les plus critiques, dans un environnement où le nombre d’infrastructures augmente et devient par conséquent plus complexe à maitriser. De plus, l’efficacité des antivirus reste dépendante de la multiplicité des attaques, et par conséquent d’une récolte efficace et complète des signatures virales.

Des mécanismes insuffisants face à l’évolutivité des cyber attaquants

Deux limites sont aujourd’hui mises en cause pour juger de la légitimité des antivirus à l’avenir. Elles sont majoritairement liées à la collecte et au stockage des bases antivirales perpétuellement alimentées.

1. Le délai de mise à jour des bases virales
   Dans un environnement constamment modelé par les cyber-attaquants, une première limite est la durée de mise à jour des banques de signatures virales. Comme rappelé par F-Secure à Gartner, « il y aura toujours un délai entre l’acquisition d’un échantillon, son analyse, et la création de la détection ». Il en découle un délai conséquent d’alimentation et d’adaptation des bases de signatures, pouvant conduire à la détection d’un virus plusieurs jours après infection.

2. Une détection principalement basée sur la recherche d’attaques connues
   Les attaques de type zero-day se caractérisent par l’absence de publication et de réponse connue à leur encontre, souvent due à leur récente réalisation. Pouvant pourtant partager des comportements avec des attaques connues, elles ne figurent pas dans le périmètre de détection des antivirus. Et bien que des mécanismes IDS (Intrusion Detection System) et de machine learning se soient greffés afin d’élargir les comportements détectés, ceux-ci ne représentent que peu de challenge pour un attaquant et sont potentiellement sources de faux-positifs.

En définitive, aucun attaquant censé ne s’est jamais entendu dire :

“D*mn there is an antivirus… Oh well too bad…”

Mais comment se prémunir face a ces attaques ?

Annoncée en préambule, la technologie EDR fait son apparition en 2013 et fonde sa stratégie sur la prévention d’attaques avancées, via l’utilisation de schémas de compromission connus. Pour cela, la clé de l’efficacité d’un EDR se trouve dans la collecte d’un maximum d’informations en continu.

A travers ses fonctions principales, un outil de Endpoint Detection and Response répond à trois besoins majeurs des équipes de sécurité des entreprises :

1.Détection    2.Investigation   3. Remédiation

Voici ci-dessous une vue globale des fonctionnalités possibles :

• Une détection intelligente en temps-réel :

• Une investigation intuitive et complète :
  • Recherche exhaustive d’indicateurs de compromission (IOC) sur l’ensemble des équipements terminaux distants (hash, nom de fichiers, date de création, taille, autres attributs) ;
  • Timeline (ou Kill-Chain) des évènements déroulés lors d’une attaque. Elle peut contenir des informations relatives aux augmentations de privilèges, aux escalades horizontales (exécution sur des machines tierces), etc.

Le détail d’un fichier peut être représenté comme suit :

• Une remédiation automatique ou sur demande :

Dans l’objectif de prioriser les interventions des équipes de sécurité, des mécanismes de scoring de la criticité des alertes permettent aux opérateurs de hiérarchiser les actions. Et, même si la suppression automatique de processus malveillants permet une première remédiation facile, d’autres remédiations « on-demand » et réalisables à distance sont envisageables :

A noter que les mécanismes présentés ci-dessus ne sont pas forcément présents dans toutes les solutions se présentant comme EDR. La présence d’un antivirus intégré n’est par exemple pas une garantie, tant l’efficacité des autres mécanismes de détection s’accélère et permet des performances de détection équivalentes.

Suivant le niveau de maturité de chaque solution, il est par conséquent nécessaire d’adopter une stratégie réalisée sur-mesure en regard des ressources matérielles/logicielles, des données métier à protéger et des ressources financières mobilisables.

Contextualisation pour une strategie sur-mesure

Une combinaison entre solutions historiques et innovantes

Puisque les EDR permettent la coexistence d’autres solutions de prévention, il n’est pas nécessaire de se séparer de son actuel antivirus afin de compléter ses défenses. Pour autant, l’aspect financier du maintien de deux solutions distinctes sur le même périmètre peut être un handicap.

De plus, certains EDR peuvent aussi intégrer des antivirus raisonnables, qui deviennent d’autant plus efficaces dans l’investigation des évènements lorsqu’ils sont liés à la même console de supervision. A l’inverse, plusieurs acteurs de solutions antivirales essayent de faire migrer leur solution vers les technologies EDR, ceci afin d’alimenter leur offre de protection Endpoint.

En se concentrant sur des scénarios adressables par la technologie EDR, nous pouvons noter la présence de solutions permettant :

1. L’utilisation d’une console d’investigation et de remédiation centralisée et permettant la protection de sites distants
2. L’interfaçage avec un SIEM ou des outils d’authentification (type Active Directory)
3. La restauration d’un OS infecté par un ransomware vers un état sain
4. L’adaptation de la remédiation opérée, afin qu’elle soit automatique ou manuelle

Des points de vigilance à adresser

Pour autant, un EDR n’est pas à considérer comme une solution miracle car :

• Il peut devenir destructeur entre de mauvaises mains, ce qui nécessite notamment un durcissement de configuration, une revue de la gestion des accès ou encore une procédure de patch management ;
• Certains mécanismes de contournement sont possibles, Wannacry en est un exemple via son utilisation d’un mécanisme de détection d’un environnement sandbox. Si une sandbox était utilisée pour l’exécuter, le virus retardait le lancement de son attaque (le temps que se déroulent les analyses de protection) afin de contourner la défense ;
• Il représente une potentielle surface d’attaque supplémentaire, avec ses propres vulnérabilités logicielles, en raison par exemple du besoin de privilèges élevés des agents déployés sur les postes.

« En 2019, les fonctionnalités des antivirus et des EDR auront fusionné dans une seule et même offre » (Gartner)

L’intérêt que représentent les EDR n’est pas anodin, comme partagé dans une étude Gartner prédisant la fusion de leurs mécanismes de détection, d’investigation et de remédiation avec un socle plus mature, celui des antivirus (source : Gartner, « Magic Quadrant for Endpoint Protection Platforms 2017 », 2017), à partir de 2019.

Le chiffre d’affaires généré par le marché des EDR a doublé entre 2015 et 2016. L’intérêt grandissant de ce domaine d’innovation laisse prédire, selon Gartner, une croissance annuelle de près de 50% du chiffre d’affaires global lié aux EDR jusqu’en 2020.

Actuellement présent sur près de 5% de l’ensemble des équipements compatibles, ce nouvel outil à la mode semble prédisposé à davantage de résonnance dans les stratégies de protection de nos postes de travail, de serveurs mais aussi de nos smartphones.

Les éditeurs

Une liste -non exhaustive- d’acteurs du monde des EDR est renseignée à titre indicatif ci-dessous.

Cet article EDR : Nouveau challenger dans la protection des endpoints est apparu en premier sur RiskInsight.

Aux origines : les Honeypots

Le principe de Deceptive Security est basé sur l’utilisation de Security Decoys (ou « leurres » en français), inspirés des Honeypots (pots de miel). Le principe est simple : des leurres sont répartis aux points stratégiques du SI et toute activité y est tracée. Ces leurres n’ayant d’autres utilités que d’appâter de potentiels attaquants, toute communication avec l’un d’entre eux est nécessairement suspecte. Leur analyse permet donc de détecter et d’étudier de potentielles menaces.

Aujourd’hui, les Honeypots demeurent peu répandus, les principaux cas d’usage restant cantonnés à des cas de recherche ou de récupération d’informations (notamment de Threat Intel). Ainsi, des « pots de miel » sont exposés publiquement afin d’observer le trafic reçu sur Internet, et d’en extraire des informations : observation de nouvelles menaces (ransomware, chevaux de Troie…), identification d’IP suspectes ou compromises (SPAM, botnet…) … On peut cependant noter le regain d’intérêt pour les honeypots suite à l’attaque WannaCry, pendant laquelle nombre d’entre eux ont été utilisés pour récupérer et analyser le ransomware.

Dans les SI des entreprises, leur utilisation est encore plus marginale, et – en plus des cas cités précédemment – majoritairement limitée à des besoins bien spécifiques de gestion de crise ou de réponse à incident. Dans ces cas, les Honeypots sont utilisés pour contenir la menace dans un périmètre défini (afin de protéger les ressources critiques), étudier son comportement et en déduire son objectif.

Ainsi, aujourd’hui, les Honeypots sont principalement utilisés dans des buts d’observation et de compréhension de la menace.

Les difficultés que les Honeypots rencontrent pour se démocratiser reposent principalement sur deux limites : ceux-ci sont généralement trop facilement détectés par les attaquants, et le passage à l’échelle d’un SI relève de l’impossible, notamment par manque d’industrialisation des solutions.

Suivre le rythme : wider, faster, stealthier

Le principe de Deceptive Security vise justement à adresser ces deux problématiques, et repose sur la capacité à déployer des leurres de manière industrielle et sur des périmètres étendus. Le déploiement de ces honeypots peut être réalisé de deux façons : par le déploiement d’environnements leurres dédiés, ou par l’ajout de leurres (agents…) installés sur des environnements existants (serveurs de production, de transfert de fichier…). La stratégie de certaines solutions de Deceptive Security repose sur le déploiement de leurres à une échelle telle que ceux-ci créent un « second SI » dans le SI (ou une partie de celui-ci), similaire à une toile d’araignée dans laquelle l’attaquant vient s’emmêler.

Même si cette industrialisation représente un progrès majeur en soi, ce qui justifie la création d’une nouvelle catégorie d’outils (plutôt que de parler de simple évolution), c’est surtout la capacité à mieux dissimuler les leurres. Terminés les serveurs vulnérables avec des mots de passe par défaut : le piège est évident, l’attaquant n’y croit plus. Aujourd’hui, les solutions de Deceptive Security les plus avancées racontent une histoire à l’attaquant afin de le guider peu à peu vers leurs pièges.

La recette : remonter les miettes jusqu’au pot de miel

Pour cela, des informations (généralement appelées “miettes”) sont disséminées sur les environnements existants : serveurs de productions, AD… Bien entendu, l’industrialisation du déploiement de ces miettes est lui aussi un des enjeux principaux mis en avant par les solutions les plus avancées. Une miette représente un brin d’information : la mention d’un serveur hébergeant un middleware obsolète, des identifiants de connexion à un serveur, l’existence d’un compte possédant des droits d’administration…

Selon les solutions, ces miettes peuvent poursuivre deux buts distincts. Elles peuvent être utilisées comme un mécanisme de protection, en guidant les attaquants vers de fausses pistes, ralentissant leur progression et les encourageant à jeter l’éponge et à changer de cible.

Mais surtout, elles peuvent aussi permettre la détection des attaquants. Dans ce cas, chacune des miettes représente un indice, que les attaquants peuvent récolter en explorant les différentes ressources du réseau. Une fois récoltés, interprétés et corrélés, ces indices guident petit à petit les attaquants vers des leurres. Et c’est ici qu’est le réel enjeu, et la rupture par rapport au positionnement classique, de la Deceptive Security : comment créer des scénarios plausibles -et variés- pour piéger les attaquants ?

Ainsi, là où les Honeypots se contentent de circonscrire l’attaquant dans un périmètre défini afin de comprendre le fonctionnement et l’objectif de l’attaque, les Security Decoys visent à être déployés sur un maximum de ressources, afin d’augmenter les chances de détection, et doivent donc savoir rester discrets.

Une fois le contact avec le leurre établi, l’attaquant est repéré. Son comportement peut être alors étudié ou son accès bloqué. Dans les cas les plus poussés, de fausses informations peuvent aussi être mises à disposition pour exfiltration, permettant de faire croire à l’attaquant que sa tentative est réussie, ou de le déstabiliser lui ou son employeur : faux secrets de fabrication ou projets de brevets, fausses stratégies de rachat…

Une nouvelle approche aux nombreux avantages

Au vu de son fonctionnement, la Deceptive Security présente certains avantages par rapport aux solutions existantes.

• La transparence pour les utilisateurs et les applications : la mise en place de leurres n’ajoute aucune contrainte aux équipes IT et utilisateurs finaux : pas d’ouverture de flux, de blocage de communication ou de fichiers légitimes… ;
• Un faible taux de fausses alertes: un leurre n’étant pas supposé être utilisé de manière légitime, tout contact a de forte chance d’être lié à une menace ;
• L’absence de connaissance des attaques pour être efficace : la protection apportée par la Deceptive Security n’est pas basée sur une connaissance préalable de la menace à détecter ou bloquer (pas de signatures…). Elle est donc à même de détecter certaines menaces inconnues (0-days sur des dispositifs de sécurité ou des middlewares…) et ne nécessite pas de mise à jour continue pour être efficace. Cependant, pour détecter de cas spécifiques – sur un type d’attaque ou une ressource ciblée par exemple -, une bonne connaissance des vecteurs d’attaques reste une nécessité pour la création de miettes convaincantes et pertinentes pour le scénario souhaité ;
• L’absence de phase d’apprentissage : la détection ou le blocage d’une menace ne repose pas non plus sur l’apprentissage du réseau (seuils, patterns…), même si une connaissance de celui-ci reste nécessaire. L’outil est donc opérationnel dès son déploiement, et n’est pas vulnérable pendant cette phase de définition de la « normalité » du réseau. Ainsi, la Deceptive Security évite les principaux inconvénients des approches par signature et par apprentissage ;
• L’absence de besoin de corrélation avec d’autres ressources: même si la corrélation avec d’autres ressources reste un plus, une simple connexion sur un leurre suffit à lever une alerte nécessitant d’étudier le cas plus en détail ;
• La possibilité de couvrir des périmètres généralement difficiles à protéger: des leurres peuvent être déployés sur de nombreux périmètres (IoT, legacy…) avec une complexité limitée, et donc apporter une nouvelle protection à ces ressources souvent non-couvertes par les dispositifs classiques.

Des cas d’usage bien spécifiques

Si la Deceptive Security permet de détecter certaines attaques classiques (malwares, scans…), le réel intérêt de ce type de solution n’est pas là, ces menaces pouvant être adressées plus efficacement par les dispositifs existants (antivirus…).

Le meilleur cas d’usage de la Deceptive Security est la détection des tentatives d’explorations fines et d’installation au sein du réseau, permettant ainsi -quand le niveau de sophistication des miettes est suffisamment important- de détecter certaines APT. Plus généralement, ce type de solution permet de détecter les mouvements latéraux au sein du réseau, et ce même avec un niveau limité de personnalisation des miettes.

Ce type de dispositif n’est donc pas destiné à remplacer les mesures existantes, mais peut agir comme complément, dans le but de détecter ces types de menaces échappant communément aux dispositifs classiques.

Et pour la suite ?

Concernant l’évolution de ces solutions, certains travaux cherchent à appliquer ce principe (déguiser les leurres en environnements de production) … mais dans l’autre sens ! En faisant passer les environnements de production pour des leurres, cette démarche à contrepied permettrait d’éviter à ces ressources d’être ciblées par les attaquants !

Les éditeurs

Une liste -non exhaustive- d’éditeurs de solution de Deceptive Security est renseignée à titre indicatif ci-dessous.

Cet article Deceptive Security : comment arroser l’arroseur ? est apparu en premier sur RiskInsight.