However, the AI threat landscape is complex, and it’s not always clear what specific teams need to do to protect an AI system. The MITRE ATLAS framework has 56 techniques available to adversaries, with mitigation being made more complex due to need to apply controls across the kill chain. Teams will require controls or mitigating measures to implement against multiple phases from reconnaissance to exfiltration and impact assessment.

Fig 1. MITRE ATLAS Kill Chain.

This complexity has led many of our clients to ask, ‘I’m the head of Identity and Access Management what do I need to know, and more importantly what do I need to do above and beyond what I’m currently doing?’.

We’ve broken down MITRE ATLAS to understand what types of controls different teams need to consider mitigating against each technique. This allows us to assess whether existing controls are sufficient and whether new controls need to be developed and implemented to secure AI systems or applications. We estimate that to assess the threat’s posed against AI systems, mitigating controls consist of 70% existing controls, and 30% new controls.

To help articulate, we’ve broken it down into three categories:

• Green domains: existing controls will cover some threats posed by AI. There may be some nuance, but the principle of the control is the same and no material adjustments need to be made.
• Yellow domains: controls will require some adaptation to confidently cover the threat posed by AI.
• Red domains: completely new controls need to be developed and implemented.

Fig 2. RAG analysis of mitigating controls for MITRE ATLAS techniques.

Green domains

Green domains are those for which existing controls will cover the risk. Three domains fall into this category: Identity & Access Management, Network Security, and Physical Security.

For IAM teams, the core principle remains ensuring the right people have access to the right things. For an AI application there is a slight nuance, as we need to consider the application itself (i.e., who can use it, who can access the source code and environment), the data used to train the model, and the input data that is used to create the output.

Network Detection and Response flags unusual activity on the network, for example the location of the request or exfiltration of large amounts of data. The network security team needs to remain vigilant and raise alerts for the same type of activity for an AI application, although it may indicate a different type of attack. Many requests to a traditional application may be indicative of a brute force attack, whereas for an AI application, it could be cost harvesting, a technique where attackers send useless queries to increase the cost of running the application, it can be mitigated through limiting the number of model queries. It is important to note that detection on the application level, and for forensics on an AI system it more complicated than a traditional application, however at the network level, the process remains the same. As with traditional applications, APIs that are integrated with the model need to be secured to ensure network interactions with public applications are secure.

Physical Security controls remain the same; secure who has physical access to key infrastructure.

Yellow domains

Controls and mitigating measures that fall into the yellow domains will follow the same principles as for traditional software but will need to be adapted to secure against the threat posed by AI. The teams that fall into this category are Education & Awareness, Resilience, and Security Operations Centre & Threat Intelligence.

For awareness teams, the techniques will remain the same, awareness campaigns, phishing tests, etc. However, they need to ensure they are updated to sufficiently reflect the new threat. For example, including deepfakes in phishing tests and ensuring new threats are covered in specific training for development teams.

While there are limited changes for the resilience team to consider, there will be some adjustments to existing processes. If an IBS is hosted or reliant on an application that utilises AI, then any testing scenarios need to include AI-specific threats.

Impacts from an attack on AI need to be added to any crisis/ incident management documentation and communication guidelines updated to reflect the possible outcomes of an AI attack, for example unexpected or offensive outputs from a customer facing Chatbot.

For a Security Operations Centre or threat intelligence team, the principle behind the controls is the same: gathering intelligence about threats and vulnerabilities and monitoring the systems for unexpected traffic or behaviour, with the addition of AI-specific threats. For AI applications, additional layers and categories of monitoring are needed to monitor for information about the model online and what other information attackers may be able to utilise to leverage access to the model. This is especially pertinent if the model is based on open-source software, for instance ChatGPT.

Red domains

Controls and techniques that fall into the red domains are totally new controls that need to be introduced to face the new threats of AI. Many sit within the data and application security team’s remit. It’s important to note that we are not referencing the data protection teams, who are largely dealing with the same issues of GDPR etc., but rather the team responsible for the security of the data, which may be the same team. The application security team have many controls within this domain, indicating the importance of building AI-enabled applications according to secure-by-design principles. There are also some AI specific controls that do not fit within existing teams. The team responsible for them is to be determined by the individual organisation, but at our more mature clients we see these owned by an AI Centre of Excellence.

Data security teams are crucial in ensuring that the training and input datasets have not been poisoned and that the data is free from bias, is trustworthy, and is reliable. These controls may be similar to existing techniques but there are nuances to consider, for instance, poisoning checks will be very similar to data quality checks. Quality data is the foundational component of a secure AI application, so it is key for teams to go beyond standard sanitization or filtering. There are many ways to do this, for example utilising an additional layer of AI to analyse the training or input data for malicious inputs. Alternatively, data tokenisation can have dual benefits: it can reduce the risk of exposing potentially private data during model training or inference and as tokenised data is in its raw form (often ACSII or Unicode characters) it becomes more difficult for attackers to introduce poisoned data into the system. Tokenisation algorithms such as Byte Pair Encoding (BPE) was used by OpenAI when pretraining the GPT model to tokenise large datasets. It is key to remember that we are not just securing the data as an artifact but assessing its content and how it could be utilised with malicious intent to create specific outputs.

Beyond securing the data as an input, data security measures should be implemented throughout the application lifecycle; when designing and building an application, while processing the inputs, and the output of the model.

Where the application is using a continuously learning model, controls around data security need to be implemented continuously while the application is running to ensure the model remains robust. Securing the training and input data provides a secure foundation, but to add an additional layer of security, continuous AI red teaming should be rolled out. This consists of continuously testing a model against adversarial inputs while it’s running. A further layer of security can be implemented by putting parameter guardrails on the type of output the model can produce.

As well as continuously testing to identify vulnerabilities in the model, application security teams must ensure the system is built according to secure-by-design principles with specific AI measures put in place. For example, when building an application internally, ensuring security requirements are applied to all components. This includes traditional software components such as the host infrastructure and AI-specific components including model configuration, training data, or, if utilising open-source models, testing the reliability of the code to identify potential security weaknesses, design flaws and alignment with secure coding standards. Application security teams need to ensure no backdoors can be built into the model. For instance, systems can be modified to enable attackers to get a predetermined output from a model using a specific trigger.

There are some application security controls that will remain the same but with an AI twist; monitoring for public vulnerabilities on software as usual, and on the model, if it’s open source.

Training for developers must continue, and the message will remain the same with some adjustments – as with traditional software, where you do not publish the version of the software that you are running, you shouldn’t publish the model or input parameters you’re using. Developers should follow the existing and updated security guidelines, understand the new threats, and build accordingly.

AI applications bring their own inherent risks that need specific controls. These need to be implemented across the lifecycle of the application to ensure it remains secure throughout. These are new controls that do not sit within an existing team. At our more mature clients, we see them managed by an AI Centre of Excellence, however for some they are the responsibility of the security team but executed by data scientists.

Specific controls need to be used in the build of the model, to ensure the model design is appropriate, the source code is secure, the learning techniques used are secure and free from bias, and there are parameters around the input and output of the model. For example, techniques such as bagging can be used to improve the resiliency of the model. This involves splitting the model into several independent sub-models during the learning phase, with the main model choosing the most frequent predictions from the sub-models. If a sub-model is poisoned, the other sub-models will compensate. Utilising techniques such as Trigger Reconstruction during the build phase can also help protect against data poisoning attacks. Trigger Reconstruction identifies events in a data stream, like looking for a needle in a haystack. For predictive models, it detects backdoors by analysing the results of a model, its architecture, and its training data. The most advanced triggers detect, understand, and mitigate backdoors by identifying a potential pain point in a deep neural network, analysing the data path to detect unusual prediction triggers (systematically erroneous results, overly rapid decision times, etc), assess back door activation by studying the behaviour of suspect data, and respond to the backdoor (filtering of problematic neurons, etc), effectively ‘closing’ it.

Fig 3. Bagging, a build technique for improving the reliability and accuracy of a model.

While running, it is key to ensure that the data being fed into the model is secure and not poisoned. This can be achieved through adding an additional layer of AI that has been trained to detect malicious data to filter and supervise of all the data inputs and detect if there is an adversarial attack.

Teams need oversight about how the model fits into the wider AI security ecosystem during the build, run, and test phases. Understanding the availability of information about the model, any new vulnerabilities, and new specific AI threats will allow them to sufficiently patch the model and conduct the appropriate tests. Especially if the model is a continuous learning model, and designed to adapt to new inputs, it needs to be tested regularly. This can be achieved in many ways, including a meta-vulnerability scan of the model, where the model’s behaviour can be modelled by formal specifications and analysed on the bases of previously identified compromise scenarios. Further adversarial learning techniques (or equivalent) should be used to ensure the continued reliability of the models.

Conclusion

We have demonstrated that despite the new threats that AI poses, existing security measures continue to provide the foundation of a secure ecosystem. Across the whole CISO function, we see a balance between existing controls that will protect AI applications in the same way they protect traditional software and the domains that need to adapt or add to what they are currently doing to protect against new threats.

From our analysis, we can conclude that to fully secure your wider ecosystem, including AI applications, your controls will be 70% existing ones, and 30% new.

Cet article Practical use of MITRE ATLAS framework for CISO teams est apparu en premier sur RiskInsight.

While there have been significant advancements, there are also challenges. For instance, Samsung’s sensitive data was exposed on ChatGPT by employees (the entire source code of a database download program)[1]. Compounding these challenges, ChatGPT [OpenAI] itself underwent a security breach that affected over 100 000 users between June 2022 and May 2023, with those compromised credentials now being traded on the Dark web[2].

At this digital crossroad, it’s no wonder that there’s both enthusiasm and caution about embracing the potential of generative AI. Given these complexities, it’s understandable why many grapple with determining the optimal approach to AI. With that in mind, the article aims to address the most representative questions asked by our clients.

Question 1: Is Generative AI just a buzz?

AI is a collection of theories and techniques implemented with the aim of creating machines capable of simulating the cognitive functions of human intelligence (vision, writing, moving…). A particularly captivating subfield of AI is “Generative AI”. This can be defined as a discipline that employs advanced algorithms, including artificial neural networks, to autonomously craft content, whether it’s text, images, or music. Moving on from your basic banking chatbot answering aside all your question, GenAI not only just mimics capabilities in a remarkable way, but in some cases, enhances them.

Our observation on the market: the reach of generative AI is broad and profound. It contributes to diverse areas such as content creation, data analysis, decision-making, customer support and even cybersecurity (for example, by identifying abnormal data patterns to counter threats). We’ve observed 3 fields where GenAI is particularly useful.

Marketing and customer experience personalisation

GenAI offers insights into customer behaviours and preferences. By analysing data patterns, it allows businesses to craft tailored messages and visuals, enhancing engagement, and ensuring personalized interactions.

No-code solutions and enhanced customer support

In today’s rapidly changing digital world, the ideas of no-code solutions and improved customer service are increasingly at the forefront. Bouygues Telecom is a good example of a leveraging advanced tools. They are actively analysing voice interactions from recorded conversations between advisors and customers, aiming to improve customer relationships[3]. On a similar note, Tesla employs the AI tool “Air AI” for seamless customer interaction, handling sales calls with potential customers, even going so far as to schedule test drives.

As for coding, an interesting experiment from one of our clients stands out. Involving 50 developers, the test found that 25% of the AI-generated code suggestions were accepted, leading to a significant 10% boost in productivity. It is still early to conclude on the actual efficiency of GenAI for coding, but the first results are promising and should be improved. However, the intricate issue of intellectual property rights concerning this AI-generated code continues to be a topic of discussion.

Documentary watch and research tool

Using AI as a research tool can help save hours in domains where regulatory and documentary corpus are very extensive (e.g.: financial sector). At Wavestone, we internally developed two AI tools. The first, CISO GPT, allows users to ask specific security questions in their native language. Once a question is asked, the tool scans through extensive security documentation, efficiently extracting and presenting relevant information. The second one, a Library and credential GPT, provides specific CVs from Wavestone employees, as well as references from previous engagements for the writing of commercial proposals.

However, while tools like ChatGPT (which draws data from public databases) are undeniably beneficial, the game-changing potential emerges when companies tap into their proprietary data. For this, companies need to implement GenAI capabilities internally or setup systems that ensure the protection of their data (cloud-based solution like Azure OpenAI or proprietary models). From our standpoint, GenAI is worth more than just the buzz around it and is here to stay. There are real business applications and true added value, but also security risks. Your company needs to kick-off the dynamic to be able to implement GenAI projects in a secure way.

Question 2: What is the market reaction to the use of ChatGPT?

To delve deeper into the perspective of those at the forefront of cybersecurity, we’ve asked our client’s CISO’s, their opinions on the implications and opportunities of GenAI. Therefore, the following graph illustrates the opinions of CISOs on this subject.

Based on our survey, the feedback from the CISOs can be grouped into three distinct categories:

The Pragmatists (65%)

Most of our respondents recognize the potential data leakage risks with ChatGPT, but they equate them to risk encountered on forums or during exchanges on platforms or forums such as Stack Overflow (for developers). They believe that the risk of data leaks hasn’t significantly changed with ChatGPT. However, the current buzz justifies dedicated sensibilization campaigns to emphasize the importance of not using company-specific or sensitive data.

The Visionaries (25%)

A quarter of the respondents view ChatGPT as a ground-breaking tool. They’ve noticed its adoption in departments such as communication and legal. They’ve taken proactive steps to understanding its use (which data, which use cases) and have subsequently established a set of guidelines. This is a more collaborative approach to define a use case framework.

The Sceptics (10%)

A segment of the market has reservations about ChatGPT. To them, it’s a tool that’s too easy to misuse, receives excessive media attention and carries inherent risks, according to various business sectors. Depending on your activity, this can be relevant when judging that the risk of data leakage and loss of intellectual property is too high compared to the potential benefits.

Question 3: What are the risks of Generative AI?

In evaluating the diverse perspectives on generative AI within organizations, we’ve classified the concerns into four distinct categories of risks, presented from the least severe to the most critical:

Content alteration and misrepresentation

Organizations using generative AI must safeguard the integrity of their integrated systems. When AI is maliciously tampered with, it can distort genuine content, leading to misinformation. This can produce biased outputs, undermining the reliability and effectiveness of AI-driven solutions. Specifically, for Large Language Models (LLMs) like GenAI, there’s a notable concern of prompt injections. To mitigate this, organizations should:

1. Develop a malicious input classification system that assesses the legitimacy of a user’s input, ensuring that only genuine prompts are processed.
2. Limit the size and change the format of user inputs. By adjusting these parameters, the chances of successful prompt injection are significantly reduced.

Deceptive and manipulative threats

Even if an organization decides to prohibit the use of generative AI, it must remain vigilant about the potential surge in phishing, scams and deepfake attacks. While one might argue that these threats have been around in the cybersecurity realm for some time, the introduction of generative AI intensifies both their frequency and sophistication.

This potential is vividly illustrated through a range of compelling examples. For instance, Deutsche Telekom released an awareness video that demonstrates the ability, by using GenAI, to age a young girl’s image from photos/videos available on social media.

Furthermore, HeyGen is a generative AI software capable of dubbing videos into multiple languages while retaining the original voice. It’s now feasible to hear Donald Trump articulating in French or Charles de Gaulle conversing in Portuguese.

These instances highlight the potential for attackers to use these tools to mimic a CEO’s voice, create convincing phishing emails, or produce realistic video deepfakes, intensifying detection and defence challenges.

For more information on the use of GenAI by cybercriminals, consult the dedicated RiskInsight article.

Data confidentiality and privacy concerns

If organizations choose to allow the use of generative AI, they must consider that the vast data processing capabilities of this technology can pose unintended confidentiality and privacy risks. First, while these models excel in generating content, they might leak sensitive training data or replicate copyrighted content.

Furthermore, concerning data privacy rights, if we examine ChatGPT’s privacy policy, the chatbot can gather information such as account details, identification data extracted from your device or browser, and information entered in the chatbot (that can be used to train the generative AI)[4]. According to article 3 (a) of OpenAI’s general terms and conditions, input and output belong to the user. However, since these data are stored and recorded by Open AI, it poses risks related to intellectual property and potential data breaches (as previously noted in the Samsung case). Such risks can have significant reputational and commercial impact on your organization.

Precisely for these reasons, OpenAI developed the ChatGPT Business subscription, which provides enhanced control over organizational data (such as AES-256 encryption for data at rest, TLS 1.2+ for data in transit, SSO SAML authentication, and a dedicated administration console)[5]. But in reality, it’s all about the trust you have in your provider and the respect of contractual commitments. Additionally, there’s the option to develop or train internal AI models using one’s own data for a more tailored solution.

Model vulnerabilities and attacks

As more organizations use machine learning models, it’s crucial to understand that these models aren’t fool proof. They can face threats that affect their reliability, accuracy or confidentiality, as it will be explained in the following section.

Question 4: How can an AI model be attacked?

AI introduces added complexities atop existing network and infrastructure vulnerabilities. It’s crucial to note that these complexities are not specific to generative AI, but they are present in various AI models. Understanding these attack models is essential to reinforcing defences and ensuring the secure deployment of AI. There are three main attack models (non-exhaustive list):

For detailed insights on vulnerabilities in Large Language Models and generative AI, refer to the “OWASP Top 10 for LLM” by the Open Web Application Security Project (OWASP).

Evasion attacks

These attacks target AI by manipulating the inputs of machine learning algorithms to introduce minor disturbances that result in significant alterations to the outputs. Such manipulations can cause the AI model to classify inaccurately or overlook certain inputs. A classic example would be altering signs to deceive AI self-driving cars (have identify a “stop” sign into a “priority” sign). However, evasion attacks can also apply to facial recognition. One might use subtle makeup patterns, strategically placed stickers, special glasses, or specific lighting conditions to confuse the system, leading to misidentification.

Moreover, evasion attacks extend beyond visual manipulation. In voice command systems, attackers can embed malicious commands within regular audio content in such a way that they’re imperceptible to humans but recognizable by voice assistants. For instance, researchers have demonstrated adversarial audio techniques targeting speech recognition systems, like those in voice-activated smart speaker systems such as Amazon’s Alexa. In one scenario, a seemingly ordinary song or commercial could contain a concealed command instructing the voice assistant to make an unauthorized purchase or divulge personal information, all without the user’s awareness[6].

Poisoning

Poisoning is a type of attack in which the attacker altered data or model to modify the ML algorithm’s behaviour in a chosen direction (e.g to sabotage its results, to insert a backdoor). It is as if the attacker conditioned the algorithm according to its motivations. Such attacks are also called causative attacks.

In line with this definition, attackers use causative attacks to guide a machine learning algorithm towards their intended outcome. They introduced malicious samples into the training dataset, leading the algorithm to behave in unpredictable ways. A notorious example is Microsoft’s chatbot, TAY, that was unveiled on Twitter in 2016. Designed to emulate and converse with American teenagers, it soon began acting like a far-right activist[7]. This highlights the fact that, in their early learning stages, AI systems are susceptible to the data they encounter. 4Chan users intentionally poisoned TAY’s data with their controversial humour and conversations.

However, data poisoning can also be unintentional, stemming from biases inherent in the data sources or the unconscious prejudices of those curating the datasets. This became evident when early facial recognition technology had difficulties identifying darker skin tones. This underscores the need for diverse and unbiased training data to guard against both deliberate and inadvertent data distortions.

Finally, the proliferation of open-source AI algorithms online, such as those on platforms like Hugging Face, presents another risk. Malicious actors could modify and poison these algorithms to favour specific biases, leading unsuspecting developers to inadvertently integrate tainted algorithms into their projects, further perpetuating biases or malicious intents.

Oracle attacks

This type of attack involves probing a model with a sequence of meticulously designed inputs while analysing the outputs. Through the application of diverse optimization strategies and repeated querying, attackers can deduce confidential information, thereby jeopardizing both user privacy, overall system security, or internal operating rules.

A pertinent example is the case of Microsoft’s AI-powered Bing chatbot. Shortly after its unveiling, a Stanford student, Kevin Liu, exploited the chatbot using a prompt injection attack, leading it to reveal its internal guidelines and code name “Sidney”, even though one of the fundamental internal operating rules of the system was to never reveal such information[8].

A previous RiskInsight article showed an example of Evasion and Oracle attacks and explained other attack models that are not specific to AI, but that are nonetheless an important risk for these technologies.

Question 5: What is the status of regulations? How is generative AI regulated?

Since our 2022 article, there has been significant development in AI regulations across the globe.

EU

The EU’s digital strategy aims to regulate AI, ensuring its innovative development and use, as well as the safety and fundamental rights of individuals and businesses regarding AI. On June 14, 2023, the European Parliament adopted and amended the proposal for a regulation on Artificial Intelligence, categorizing AI risks into four distinct levels: unacceptable, high, limited, and minimal[9].

US

The White House Office of Science and Technology Policy, guided by diverse stakeholder insights, presented the “Blueprint for an AI Bill of Rights”[10]. Although non-binding, it underscores a commitment to civil rights and democratic values in AI’s governance and deployment.

China

China’s Cyberspace Administration, considering rising AI concerns, proposed the Administrative Measures for Generative Artificial Intelligence Services. Aimed at securing national interests and upholding user rights, these measures offer a holistic approach to AI governance. Additionally, the measures seek to mitigate potential risks associated with Generative AI services, such as the spread of misinformation, privacy violations, intellectual property infringement, and discrimination. However, its territorial reach might pose challenges for foreign AI service providers in China[11].

UK

The United Kingdom is charting a distinct path, emphasizing a pro-innovation approach in its National AI Strategy. The Department for Science, Innovation & Technology released a white paper titled “AI Regulation: A Pro-Innovation Approach”, with a focus on fostering growth through minimal regulations and increased AI investments. The UK framework doesn’t prescribe rules or risk levels to specific sectors or technologies. Instead, it focuses on regulating the outcomes AI produces in specific applications. This approach is guided by five core principles: safety & security, transparency, fairness, accountability & governance, and contestability & redress[12].

Frameworks

Besides formal regulations, there are several guidance documents, such as NIST’s AI Risk Management Framework and ISO/IEC 23894, that provide recommendations to manage AI-associated risks. They focus on criteria aimed at trusting the algorithms in fine, and this is not just about cybersecurity! It’s about trust.

With such a broad regulatory landscape, organizations might feel overwhelmed. To assist, we suggest focusing on key considerations when integrating AI into operations, in order to setup the roadmap towards being compliant.

• Identify all existing AI systems within the organization and establish a procedure/protocol to identify new AI endeavours.
• Evaluate AI systems using criteria derived from reference frameworks, such as NIST.
• Categorize AI systems according to the AI Act’s classification (unacceptable, high, low or minimal).
• Determine the tailored risk management approach for each category.

Bonus Question: This being said, what can I do right now?

As the digital landscape evolves, Wavestone emphasizes a comprehensive approach to generative AI integration. We advocate that every AI deployment undergo a rigorous sensitivity analysis, ranging from outright prohibition to guided implementation and stringent compliance. For systems classified as high risk, it’s paramount to apply a detailed risk analysis anchored in the standards set by ENISA and NIST. While AI introduces a sophisticated layer, foundational IT hygiene should never be side lined. We recommend the following approach:

• Pilot & Validate: Begin by gauging the transformative potential of generative AI within your organizational context. Moreover, it’s essential to understand the tools at your disposal, navigate the array of available choices, and make informed decisions based on specific needs and use cases.
• Strategic Insight: Based on our client CISO survey, ascertain your ideal AI adoption intensity. Do you resonate with the 10%, 65% or 25% adoption benchmarks shared by your industry peers?
• Risk Mitigation: Ground your strategy in a comprehensive risk assessment, proportional to your intended adoption intensity.
• Policy Formulation: Use your risk-benefit analysis as a foundation to craft AI policies that are both robust and agile.
• Continuous Learning & Regulatory Vigilance: Maintain an unwavering commitment to staying updated with the evolving regulatory landscape. Both locally and globally, it’s crucial to stay informed about the latest tools, attack methods, and defensive strategies.

[1]  Des données sensibles de Samsung divulgués sur ChatGPT par des employés (rfi.fr)

[2] https://www.phonandroid.com/chatgpt-100-000-comptes-pirates-se-retrouvent-en-vente-sur-le-dark-web.html

[3] Bouygues Telecom mise sur l’IA générative pour transformer sa relation client (cio-online.com)

[4] Quelles données Chat GPT collecte à votre sujet et pourquoi est-ce important pour votre vie privée en ligne ? (bitdefender.fr)

[5] OpenAI lance un ChatGPT plus sécurisé pour les entreprises – Le Monde Informatique

[6] Selective Audio Adversarial Example in Evasion Attack on Speech Recognition System | IEEE Journals & Magazine | IEEE Xplore

[7] Not just Tay: A recent history of the Internet’s racist bots – The Washington Post

[8] Microsoft : comment un étudiant a obligé l’IA de Bing à révéler ses secrets (phonandroid.com)

[9] Artificial intelligence act (europa.eu)

[10] https://www.whitehouse.gov/wp-content/uploads/2022/10/Blueprint-for-an-AI-Bill-of-Rights.pdf

[11] https://www.china-briefing.com/news/china-to-regulate-deep-synthesis-deep-fake-technology-starting-january-2023/

[12] A pro-innovation approach to AI regulation – GOV.UK (www.gov.uk)

Cet article AI: Discover the 5 most frequent questions asked by our clients! est apparu en premier sur RiskInsight.

IAM is a far-reaching concept. This understanding must be put into practice when running such a programme, to avoid quickly falling into common pain points. Let’s take a closer look.

IAM programme challenges: some typical examples

Three main drivers which are putting demands on IAM are business change, cyber security, and user experience. However, organisations often undertake IAM programmes driven, exclusively or primarily, by the desire to migrate to a new solution. With technical debt or tooling the only real concern, IAM programmes can face issues very quickly.

1/ Broad impacts of migrating to a new solution

Often the desire is to simply migrate to a new tool or perform a major upgrade of the existing technical asset, whilst leaving all other elements of the IAM service unchanged. This can have unwanted effects on these other aspects. For example, a new tool will likely bring about new approval processes, which will require staff training on a new user interface. It could even require entirely new leavers and joiners’ processes for HR. This pain point ultimately boils down to a lack of assessment of the impact of the technology change, in the context of wider IAM ecosystem.

2/ An ever-growing list of requirements

When an organisation realises that IAM change is not limited to the tooling, this can often open the floodgates to an unrealistic number of new objectives. Stakeholders end up demanding more of the programme (such as better user experience and increased ITSM integration) – despite these new objectives not being originally identified and catered for. The programme can become a vehicle to voice dissatisfaction with the existing end-to-end IAM service, causing scope creep. This dynamic can quickly bring pain to the programme across change management, budget, and solution architecture.

3/ Forcing a like-for-like implementation

Once interactions between the new IAM solution and its perimeter services are fully functioning, you still need to consider differences in design philosophies between the new and the old tool. Key product design differences must be catered for. If not, organisations can end up requiring custom code and complex configurations on the new solution, simply to match the previous setup. This can impact on vendor support, maintenance, overall performance – and not to mention the need to retain a huge body of knowledge on the complex customisation. By going down this road, you can cause more trouble than that you are trying fix. A true butterfly effect of issues can be on the cards when trying to force a like-for-like on different tools.

The key to avoiding these common pain points is to acknowledge that IAM must be viewed as a transversal topic, which impacts technology, people, and processes.

What is the recommended approach then?

Key to success is the acknowledgement that IAM improvement is a far-reaching programme. The implementation of new solutions is only the tip of the iceberg, and key impacts should not be underestimated. Under the covers, we believe the key streams of the transformation are:

/ IAM solution renewal: the deployment (or upgrade) of the new IAM solution. This includes solution architecture, engineering, and technical migration.

/ Modelling of rights: existing access rights must be translated into the new IAM ecosystem, such as business roles and application profiles.

/ IAM data cleansing: the stream to review, cleanse, and validate reliability and correctness of existing user data. For example, recertifying the role of a user and validating their line manager to ensure the correct person is approving access requests.

/ New processes and change management: this includes new ways to request and review access to applications, new processes to manage leavers and joiners, and training staff.

/ Interoperability with other services and assets in the IS: for example, integrating the new IAM tooling with the SOC may require re-engineering the log ingestion into the SIEM and API calls. Another typical piece of work is to coordinate with concurrent AD migrations or upgrades.

We recommend structuring the IAM programme such that each of these topics is covered by an individual project. The design authority of IAM policies should operate at the programme level, with clear inputs to help guide all streams.

Critical to success is also strong sponsorship and a publicized vision of the objectives. Because IAM programmes touch so many organisational domains, it is essential that the programme manager and PMO function are supported at the executive level.

Finally, flexibility is key to manage changing circumstances and constraints. Here’s other tips to ensure the programme can remain on track to meet its intended objectives:

/ Find a good middle ground between legacy assets, the ideal target state & the capabilities of the new solution: the target state should be based on what best helps deliver the end-to-end IAM service to the business.

/ Evaluate the possibility of integrating new solutions with existing services, even if not originally envisaged in the ideal target state. Simplify and rationalise where possible. This will help in both the short term and the long term.

/ Do not rule out the possibility of retaining existing tools which were originally due for decommission, if it supports the overarching IAM objectives: sometimes it is best to maintain some existing assets, rather than decommission and migrate for the sake of IT modernisation.

In this article we have seen how defining key objectives is vital for the success of the programme. Understanding the breadth of IAM change is crucial, both for structuring the programme, and delivering on time and on budget. This approach will also allow programme managers and each stream lead to implement flexible measures to migrate from a legacy ecosystem and legacy applications to the new sol

Cet article Identity and Access Management: keys to a successful transformation programme est apparu en premier sur RiskInsight.

IAM transformation: what are the main drivers?

Businesses are changing at pace, and speed-to-market is strongly dependant on IT systems built on robust and scalable identity services. Whether it’s new a web service available to customers, a significant expansion, or a back-office merger – the requirement to scale IAM services quickly and efficiently is ever-present.

At Wavestone, we witness three drivers, often in combination, which demand more from Identity & Access Management:

1. Cybersecurity risks
2. Business change
3. End user experience

Let’s dive into each of these in more detail:

1/ Evolving cybersecurity and information system models

Information systems are increasingly open and fragmented. Cloud adoption and distributed architectures are contributing to this fundamental shift. Security is adapting its principles and the notion of zero trust is now well established. Identity and access management is a key enabler for zero trust.

Information systems are consumed by thirds parties, customers, and employees. Identity is central to critical data exchange and confidentiality amongst diverse entities. It is therefore necessary to have a unique identity for each entity across the entire information system. While architectures evolve – the ultimate IAM objective does not: the right person or entity, with the appropriate level of rights, to access the right resource, in the right context. Crucially, this principle must be met on an ongoing basis.

Each machine and user’s unique identity is also critical for traceability. An organisation should be able to identify, authenticate and authorise any user, from any other entity, when accessing a resource. The ability to centrally log, audit and monitor these events from across the information system is essential.

2/ Identity-as-a-service to the business

Businesses are experiencing core transformation which require more agility & shorter time-to-market. For example, several retailers are seeking new digital avenues to market due to an evolving e-commerce landscape and operational challenges brought about by the COVID-19 pandemic. Identity services must be able to support large business initiatives and cater for innovation at scale.

Complex business change cannot be slowed down by extended security or infrastructure delivery times. Identity must be an enabler, and not synonymous with delay. Any project must be able to rely on identity services which are provided as an available commodity to the business, and not newly designed and deployed for each initiative.

Consolidation and standardisation of IAM solutions and processes is critical to implementing this model. This includes consistent and robust management and is dependent on technology-agnostic methods and protocols – based on the latest, secure, industry standards (such as SAML, OIDC and OAuth).

The provision of identity services must become embedded in the organisation’s operating model and practices such as Agile, DevOps @ scale and innovation @ scale: IAM delivered as a service to the business.

3/ User experience demands are now centre stage

The third, crucial, driver of IAM transformation is user experience. The focus is on organisations to provide employees with the same quality of authentication and authorisation services that external customers have often enjoyed in the past. The objective is to allow end users to prove their identity easily and effortlessly, and access required services, from anywhere, and from any device. This forms the basis for a genuine continuous experience that supports new ways of collaborating, also accelerated by remote working.

Easy and smooth registration processes, as well as consistent authentication across different applications, should be provided to customers to simplify their experience and build brand loyalty. This same principle holds for employees and third parties.

Passwordless technologies and unique application logins are examples of solutions on the rise; Innovative risk-based and contextual approaches can streamline accesses, which can have a significant, positive, impact on user experience by reducing authentication requests.

What steps to IAM transformation?

Understanding your current maturity is a key step towards delivering on the above. Over years of supporting IAM initiatives with clients, we have built our IAM maturity improvement journey, which is comprised of 4 maturity steps.

• Fragmented: the organisation lacks a consolidated approach to IAM across solutions, governance, and standards.

• Rationalized: the technology landscape supporting IAM is simplified and managed centrally to aid user experience across all applications and users. Consolidation provides satisfactory oversight capabilities.

• Extended: the organisational IAM capabilities cater for an evolving information system: any user, any device, any service.

Many organisations currently have elements of these capabilities, but rarely deployed globally.

• Mastered: the organisation has adopted next-gen solutions, which provide strong security benefits and a smooth user experience – all whist reducing the workload on IT operations thanks to intelligent automation.

At the time of writing, these are adopted on a case-by-case basis or serve as an aspirational step on IAM roadmaps.

Each of the above steps requires a deep transformation of the environment: change of governance, change of processes, and deployment or migration of supporting technologies. To be a success, we believe it needs to be addressed as a dedicated IAM transformation programme.

Stay tuned for our next publication, where we share what good looks like for an IAM transformation programme…

Cet article Identity and Access Management: back in the spotlight est apparu en premier sur RiskInsight.

The Workplace and its Collaboration Tools

It’s great to be able to work from anywhere, any device and having the technology work when you need it. More than a luxury, it’s a necessity in the current intensified remote working situation, or for international organisations with very mobile, distributed, fluid users. While so many changes happen during the crisis, your workplace should support your business reconfiguration through enabling staff, partners, suppliers to work with different applications, different teams, etc.

The word “Workplace” used in this context refers to more than the workstations and collaboration tools. It extends to wider areas such as enterprise architecture, application security & identity and access management. Arguably, we’re talking about the wider IT foundation/digital capabilities, to support and enable business needs – the workplace might just be the tip of the iceberg.

Legacy upon Legacy adds Complexity

On the user side, as soon as you go through multiple use-cases, e.g. accessing a legacy system on premise or a Software as a Service application, you are likely to require multiple accounts and therefore a cumbersome user experience.

On the IT operation side, it is equally a burden to make it work: workstations are still most of the time a physical device bound to a rigid corporate domain; they need to be configured, then shipped to remote staff or external parties, and accounts still need to be provisioned in target environments, with access rights set appropriately. All the above usually being different processes which are repeated for each supplier or partner, leading to as many devices and set ups.

More importantly, how secure is this disorganised and overlapping situation? Having visibility and control on who has access to what, end to end and for all environments, is a challenge because of the siloed use-cases. And as users join and leave, applications evolve, the security level likely decreases by lack of keeping accounts and rights accurate.

In our experience at Wavestone, all these challenges stem from the accumulation of new use-cases and technology, implemented in silo, for their own use or limited group of use-cases. The platform, which was first designed with one primary use, has now altered into a manifold use platform with an ill-fitting model and processes. Many organisations today can be proud to rely on a federated platform and modern access experience for cloud applications on one side – and a different, yet reasonably good, experience on internal applications side. However, often both are not integrated and therefore don’t get the benefits we described in the introduction. We believe this comes from the lack of a truly shared model/architecture to support a modern experience, across all use-cases.

.

Figure 1 – Example of a corporate model in which each entity manages identities and their access separately: duplicating processes

One Model for a streamline experience

For this reason and for the future of user experience, at Wavestone we believe in a model based on Identity Control Tower(s).

An Identity Control Tower is a platform to enforce your access policies. Its purpose is to verify access requests coming from trusted sources of identity and determine if that identity is allowed to access a target digital resource. For the metaphor, a pilot willing to get clearance for take-off will submit their flight plan using a trusted channel, and after its approval and other verification by controllers, the pilot can proceed to take-off. If we were to transpose this metaphor digitally, we would talk about a user: in order for said user to access X platform, (s)he would need to use a corporate process which itself is trusted by an Identity Control Tower. Said user would provide their “access plan” (e.g. session token) to the Identity Control Tower. After the Identity Control Tower has verified the authenticity of the “access plan” against its access policies it will perform other checks of context, such as: time of the request, location of origin of the access, trust level of the device etc, the user can then proceed to access the resources. Should these verifications highlight anything unusual or inconsistent in authenticating the user, additional requests can be made to allow the user in (re-authentication or step up).

The Identity Control Tower is under your control and holds the conditions of access i.e. access policies and accepts users from specific sources thanks to a pre-established trust relationship between organisations.

For instance, in the diagram below, imagine a situation in which a supplier is developing a new service in your cloud environment. Users from the supplier would keep their device and authentication process they use within their corporate environment, while the Identity Control Tower (ICT) would enforce access control to the cloud environment – without having to use and manage a different account and re-authenticate. For environments with very granular privileges like AWS, building a decoupled ICT is maybe not a realistic approach and the ICT is then probably the identity platform from Amazon that is managed by your organisation and linked to the identity provider of the supplier. The Identity Control Tower model is basically an extension of federation, implemented to cover all use-cases.

Figure 2 – Access of a Partner user to a Cloud Provider resource through an Identity Control Tower

In another scenario, as seen in this diagram, let’s consider an applicant applying for a job in your organisation, thanks to a recruitment portal you offer. They would initiate an application in your portal using their government-backed digital identity, and once they provide their consent to access their LinkedIn profile, you could obtain a digital CV. For the applicant, it is as simple as showing their ID and giving a copy of their CV, rather than filling-in registration form(s) asking once again for the same standard identity information and risking a typo in their contact details – or even having to send copies of sensitive documents like their passport.

Figure 3 – An alternative scenario presenting the trust relationship between a government ID platform and the corporate

One Model, Three Key Pillars

Using our knowledge and experience, we believe that this model should be built upon three key pillars: a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship.

A Unique Identity Architecture: this is achieved by following a simple rule: don’t duplicate identity data. The less identity records you create for the same physical person, the more streamline the digital experience will be – as cumbersome steps start to appear when an additional account, device or authentication action is required for the user to access the target resource. The key behind a unique identity data is to try reusing the data from its (authoritative) source instead of duplicating/copying it in your own systems. For instance, the suppliers or partners working with your organisation likely already have professional digital identities for their own IT use – what would be the conditions to leverage them instead of re-creating them?[1] The next two pillars contribute to answering this question.

A Common and Flexible Model: The second pillar is to use a common and flexible model to allow/restrict access to information. To provide flexibility, an attribute-based access control (ABAC) model enables granular rules and is well suited to a risk-based and adaptive approach. To make it work though, it is essential to define the “grammar” of the authorisation model: what are the actual attributes used to provide accesses that make sense at the enterprise level? How do they translate into “privileges”? What are their formats/values? When the Identity Control Tower is provided by a cloud provider (e.g. from a Cloud provider as Azure or AWS), the grammar is often determined by the said service. Furthermore, to make this model as widespread as possible across use-cases, both on the identity source side and on providing access on the target service side, we recommend implementing your platform following market standards to maximise inter-operability (SAML, OpenID Connect, OAuth, FIDO, etc.).

360° Trust Relationship: Finally, the last pillar is to ensure the establishment of a 360° Trust Relationship. In other words, perform due diligence and establish confidence thresholds to accept interconnection (“technical trust”) of identity platforms. The due diligence should extend to all upstream processes leading to feeding the platform with identities, for instance the HR/procurement processes to vet identities, up to the IT on-boarding process itself – because trusting an identity platform is a first step for these identities to access your digital resources, you need to be within tolerance of the risk it comes with. This trust relationship should then be implemented through security level expectations, auditability in contractual clauses, and enforced via the supplier service management governance. With such strong requirements, one organisation must be prepared to temporarily on-board suppliers or partners within the organisation’s own platform, while suppliers or partners remediate their processes and platforms to be compliant.

Two key success factors

In order to implement these three key pillars, Wavestone has identified two key success factors: being sponsored by appropriate level of management and building resilience and privacy by design. A transformation programme to establish this model would have implications and requirements in several of your organisation’s departments (HR, sourcing, legal, IT, risk, security etc.), hence should be sponsored by top-management and driven with a pan-organisation approach.
Additionally, as it should always be, the supporting platform should be designed and built with security, privacy and resilience considerations from the beginning.

Final Thoughts

As you have been able to understand throughout this article, looking at the user experience end to end and across use-cases is key to really streamline digital services. This can be achieved with a pan-organisation shift to enforce a unique identity across all systems, a common and flexible model to access information and, the establishment of a 360° trust relationship with third parties.

To go further in your reflection on the subject and understand the current state of your organisation, think about these questions and try to answer them: picking users from different departments, what does the typical day to day digital experience look like? How long does my organisation take to on-board contractors and third parties? How does my organisation actually give access to its data and resources for external users? How many duplicate identities exist across my IT estate?

[1] A technical entry might still exist within your systems, for reference purposes – but from the user perspective there is no new account, no duplicate, if they don’t have to register a new login, credentials etc.

Cet article Key Enablers in Creating a Seamless and Secure User Experience est apparu en premier sur RiskInsight.

Le lieu de travail et ses outils de collaboration

C’est formidable de pouvoir travailler de n’importe où, avec n’importe quel appareil et de disposer de la technologie nécessaire quand on en a besoin. Plus qu’un luxe, c’est une nécessité dans la situation actuelle de travail à distance intensifié, ou pour les organisations internationales dont les utilisateurs sont très mobiles, répartis et fluides. Alors que tant de changements se produisent pendant la crise, votre lieu de travail devrait soutenir la reconfiguration de votre entreprise en permettant au personnel, aux partenaires, aux fournisseurs de travailler avec différentes applications, différentes équipes, etc.

Le mot “lieu de travail” utilisé dans ce contexte ne se limite pas aux postes de travail et aux outils de collaboration. Il s’étend à des domaines plus larges tels que l’architecture d’entreprise, la sécurité des applications et la gestion des identités et des accès. On peut dire que nous parlons de la base informatique plus large et des capacités numériques, pour soutenir et répondre aux besoins des entreprises – le lieu de travail n’est peut-être que la partie visible de l’iceberg.

L’héritage sur l’héritage ajoute de la complexité

Du côté de l’utilisateur, dès que vous passez par plusieurs cas d’utilisation, par exemple l’accès à un système existant sur place ou à une application Software as a Service, vous êtes susceptible d’avoir besoin de plusieurs comptes et donc d’une expérience utilisateur lourde.

Du côté de l’exploitation informatique, c’est également un fardeau de la faire fonctionner : les postes de travail sont encore la plupart du temps un dispositif physique lié à un domaine rigide de l’entreprise ; ils doivent être configurés, puis expédiés au personnel distant ou à des parties externes, et les comptes doivent encore être approvisionnés dans des environnements cibles, avec des droits d’accès définis de manière appropriée. Tous les éléments ci-dessus sont généralement des processus différents qui se répètent pour chaque fournisseur ou partenaire, ce qui entraîne autant de dispositifs et de configurations.

Plus important encore, dans quelle mesure cette situation désorganisée et chevauchante est-elle sûre ? Avoir une visibilité et un contrôle sur qui a accès à quoi, de bout en bout et pour tous les environnements, est un défi en raison des cas d’utilisation cloisonnés. Et à mesure que les utilisateurs rejoignent et quittent l’entreprise, que les applications évoluent, le niveau de sécurité diminue probablement en raison du manque de précision des comptes et des droits.

D’après notre expérience chez Wavestone, tous ces défis découlent de l’accumulation de nouveaux cas d’utilisation et de nouvelles technologies, mis en œuvre en silo, pour leur propre usage ou pour un groupe limité de cas d’utilisation. La plateforme, qui a d’abord été conçue pour une utilisation principale, s’est maintenant transformée en une plateforme à utilisations multiples avec un modèle et des processus mal adaptés. De nombreuses organisations peuvent aujourd’hui être fières de pouvoir compter sur une plate-forme fédérée et une expérience d’accès moderne pour les applications en nuage d’un côté – et sur une expérience différente, mais raisonnablement bonne, du côté des applications internes. Cependant, souvent, les deux ne sont pas intégrés et ne bénéficient donc pas des avantages que nous avons décrits dans l’introduction. Nous pensons que cela est dû à l’absence d’un modèle/architecture véritablement partagé pour soutenir une expérience moderne, dans tous les cas d’utilisation.

Figure 1 – Exemple de modèle d’entreprise dans lequel chaque entité gère séparément les identités et leur accès : duplication des processus

Un modèle pour une expérience de rationalisation

Pour cette raison et pour l’avenir de l’expérience utilisateur, chez Wavestone, nous croyons en un modèle basé sur la ou les Tours de Contrôle d’Identité.

Une tour de contrôle d’identité est une plate-forme permettant de faire respecter vos politiques d’accès. Son but est de vérifier les demandes d’accès provenant de sources d’identité fiables et de déterminer si cette identité est autorisée à accéder à une ressource numérique cible. Pour reprendre la métaphore, un pilote désireux d’obtenir une autorisation de décollage soumettra son plan de vol en utilisant un canal de confiance, et après son approbation et d’autres vérifications par les contrôleurs, le pilote pourra procéder au décollage. Si nous devions transposer cette métaphore en numérique, nous parlerions d’un utilisateur : pour que ledit utilisateur puisse accéder à la plate-forme X, il devrait utiliser un processus d’entreprise qui est lui-même fiable par une tour de contrôle d’identité. Cet utilisateur fournit son “plan d’accès” (par exemple, un jeton de session) à la tour de contrôle d’identité. Après que la tour de contrôle d’identité a vérifié l’authenticité du “plan d’accès” par rapport à ses politiques d’accès, elle effectuera d’autres vérifications de contexte, telles que : l’heure de la demande, le lieu d’origine de l’accès, le niveau de confiance du dispositif, etc. Si ces vérifications mettent en évidence quelque chose d’inhabituel ou d’incohérent dans l’authentification de l’utilisateur, des demandes supplémentaires peuvent être faites pour permettre à l’utilisateur d’entrer (ré-authentification ou renforcement).

La tour de contrôle d’identité est sous votre contrôle et détient les conditions d’accès, c’est-à-dire les politiques d’accès et accepte les utilisateurs de sources spécifiques grâce à une relation de confiance préétablie entre les organisations.

Par exemple, dans le schéma ci-dessous, imaginez une situation dans laquelle un fournisseur développe un nouveau service dans votre environnement en nuage. Les utilisateurs du fournisseur conserveraient leur dispositif et le processus d’authentification qu’ils utilisent dans leur environnement d’entreprise, tandis que la tour de contrôle d’identité (TIC) imposerait un contrôle d’accès à l’environnement en nuage – sans avoir à utiliser et à gérer un compte différent et à se ré-authentifier. Pour les environnements avec des privilèges très granulaires comme AWS, construire une TIC découplée n’est peut-être pas une approche réaliste et la TIC est alors probablement la plateforme d’identité d’Amazon qui est gérée par votre organisation et liée au fournisseur d’identité du fournisseur. Le modèle de la tour de contrôle d’identité est essentiellement une extension de la fédération, mise en œuvre pour couvrir tous les cas d’utilisation.

Figure 2 – Accès d’un utilisateur partenaire à une ressource du fournisseur de services dans le nuage via une tour de contrôle d’identité

Dans un autre scénario, comme le montre ce schéma, considérons un candidat qui postule à un emploi dans votre organisation, grâce à un portail de recrutement que vous proposez. Il déposerait une candidature sur votre portail en utilisant son identité numérique soutenue par le gouvernement, et une fois qu’il aurait donné son accord pour accéder à son profil LinkedIn, vous pourriez obtenir un CV numérique. Pour le candidat, il suffit de montrer sa pièce d’identité et de donner une copie de son CV, plutôt que de remplir le(s) formulaire(s) d’inscription en demandant une nouvelle fois les mêmes informations d’identité standard et en risquant de faire une faute de frappe dans ses coordonnées – ou même de devoir envoyer des copies de documents sensibles comme son passeport.

Figure 3 – Un scénario alternatif présentant la relation de confiance entre une plateforme d’identification gouvernementale et l’entreprise

Un modèle, trois piliers clés

Forts de nos connaissances et de notre expérience, nous pensons que ce modèle devrait reposer sur trois piliers clés : une identité unique dans tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360°.

Une Architecture d’Identité Unique : elle est réalisée en suivant une règle simple : ne pas dupliquer les données d’identité. Moins vous créez de fiches d’identité pour une même personne physique, plus l’expérience numérique sera simplifiée – car des étapes lourdes commencent à apparaître lorsqu’un compte, un dispositif ou une action d’authentification supplémentaire est nécessaire pour que l’utilisateur accède à la ressource cible. La clé d’une donnée d’identité unique est d’essayer de réutiliser les données de sa source (qui fait autorité) au lieu de les dupliquer/copier dans vos propres systèmes. Par exemple, les fournisseurs ou partenaires travaillant avec votre organisation ont probablement déjà des identités numériques professionnelles pour leur propre usage informatique – quelles seraient les conditions pour les exploiter au lieu de les recréer ?  Les deux piliers suivants contribuent à répondre à cette question.

Un modèle commun et flexible : Le deuxième pilier consiste à utiliser un modèle commun et flexible pour permettre/restreindre l’accès à l’information. Pour assurer la flexibilité, un modèle de contrôle d’accès basé sur les attributs (ABAC) permet des règles granulaires et est bien adapté à une approche adaptative et basée sur les risques. Pour que cela fonctionne, il est toutefois essentiel de définir la “grammaire” du modèle d’autorisation : quels sont les attributs réels utilisés pour fournir des accès qui ont un sens au niveau de l’entreprise ? Comment se traduisent-ils en “privilèges” ? Quels sont leurs formats/valeurs ? Lorsque la tour de contrôle d’identité est fournie par un fournisseur de cloud (par exemple, par un fournisseur de cloud comme Azure ou AWS), la grammaire est souvent déterminée par ledit service. En outre, pour que ce modèle soit le plus répandu possible dans les cas d’utilisation, tant du côté de la source d’identité que de la fourniture d’accès du côté du service cible, nous recommandons de mettre en œuvre votre plate-forme en suivant les normes du marché afin de maximiser l’interopérabilité (SAML, OpenID Connect, OAuth, FIDO, etc.).

Une relation de confiance à 360° : Enfin, le dernier pilier consiste à assurer l’établissement d’une relation de confiance à 360°. En d’autres termes, il faut faire preuve de diligence raisonnable et établir des seuils de confiance pour accepter l’interconnexion (“confiance technique”) des plateformes d’identité. La diligence raisonnable doit s’étendre à tous les processus en amont qui permettent d’alimenter la plateforme en identités, par exemple les processus RH/achats pour vérifier les identités, jusqu’au processus d’intégration informatique lui-même – parce que la confiance dans une plateforme d’identité est une première étape pour que ces identités puissent accéder à vos ressources numériques, vous devez être dans la tolérance du risque qu’elle comporte. Cette relation de confiance doit ensuite être mise en œuvre par le biais des attentes en matière de niveau de sécurité, de l’auditabilité des clauses contractuelles, et être appliquée par le biais de la gouvernance de la gestion des services des fournisseurs. Avec des exigences aussi strictes, une organisation doit être prête à intégrer temporairement des fournisseurs ou des partenaires au sein de sa propre plate-forme, pendant que les fournisseurs ou partenaires remettent leurs processus et plates-formes en conformité.

Deux facteurs clés de succès

Afin de mettre en œuvre ces trois piliers clés, Wavestone a identifié deux facteurs clés de succès : être parrainé par un niveau de gestion approprié et renforcer la résilience et la protection de la vie privée dès la conception. Un programme de transformation visant à établir ce modèle aurait des implications et des exigences dans plusieurs départements de votre organisation (RH, approvisionnement, juridique, informatique, risques, sécurité, etc.), et devrait donc être parrainé par la direction générale et mené avec une approche panorganisationnelle.

En outre, comme toujours, la plateforme de support doit être conçue et construite en tenant compte dès le départ des questions de sécurité, de confidentialité et de résilience.

Réflexions finales

Comme vous avez pu le comprendre tout au long de cet article, il est essentiel d’examiner l’expérience de l’utilisateur de bout en bout et d’un cas d’utilisation à l’autre pour vraiment rationaliser les services numériques. Cela peut être réalisé grâce à un changement d’organisation pour imposer une identité unique à tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360° avec les tiers.

Pour aller plus loin dans votre réflexion sur le sujet et comprendre l’état actuel de votre organisation, réfléchissez à ces questions et essayez d’y répondre : en choisissant des utilisateurs de différents services, à quoi ressemble l’expérience numérique quotidienne typique ? Combien de temps faut-il à mon organisation pour embarquer des sous-traitants et des tiers ? Comment mon organisation donne-t-elle effectivement accès à ses données et ressources aux utilisateurs externes ? Combien d’identités doubles existe-t-il dans mon parc informatique ? 

Cet article Les facteurs clés pour créer une expérience utilisateur transparente et sécurisée est apparu en premier sur RiskInsight.

Cybersecurity remains a fast-evolving ecosystem that presents new threats to enterprises every day with hackers becoming increasingly innovative in their attempts to break into corporate networks and steal valuable data. As such, cybersecurity start-ups are playing an even more critical role in providing disruptive and innovative solutions to novel cybersecurity challenges.

Discover our infographic on the 2019 UK cybersecurity start-up landscape to find out the latest market trends, our key findings in this area and a booming UK market.

Cet article 2019 UK Cybersecurity Startup Radar est apparu en premier sur RiskInsight.

Consequently, organisations are looking for ways to become cyber-resilient and thus limit the impacts of such attacks. Besides this, more regulations related to cyber-resilience are emerging and pushing organisations to take appropriate action; particularly when incentivised by the threat of exposure to possible sanctions and fines for non-compliance.

How is the UK regulatory framework developing on this topic? What have we learned from recent major cyberattacks? How should organisations prepare to react promptly and effectively in case of such attacks?

Cyber-resilience in the UK – An increasingly restrictive regulatory framework

NIS Regulations, the first implementation of cyber-resilience principles in UK law

Following the European Union directive on the security of Networks and Information Systems (NIS directive) and despite Brexit, the NIS Regulations came into force in the UK on 10th May 2018. This regulation has marked a clear shift of the regulators’ role from a helpful supportive party to a more restrictive one.

As per this regulation, Operators of Essential Services (OES) and Digital Service providers (DSP) must consider cyber-security measures to manage the security of their systems and facilities, their existing processes and procedures to handle security breaches and maintain business continuity.

OES, who had to register to their Competent Authority (CA – i.e. regulator identified for sector) by the 20th August 2018, are considered as more critical than the DSPs in the event of an attack; and hence why they face much stricter requirements. Therefore, OES are subject to audits conducted by their CA’s. These controls will assess organisations against the 14 security principles outlined in the Cyber-assessment framework published by the UK National Cyber Security Centre (NCSC).

If there is non-compliance with the NIS Regulations, organisations are now exposed to sanctions that can go from notices for further information to monetary penalties (up to a maximum of £17 million).

DSP’s will not be audited, they will only face enquiries in case of incident. They have also been given more time to register to their CA with a deadline of the 1st November 2018. For organisations falling into the OES / DSP scope, not registering is considered as a blatant violation of the NIS Regulations, and could lead to severe disciplinary action.

Cyber-resilience regulation for the UK financial sector

Financial services have always been considered as ‘one-step-ahead’ when it comes to Cyber-resilience. Therefore, this market is a good indicator of the future trends related to this topic.

Surprisingly, the Banking and Financial Market infrastructure sectors are not listed as OES by the NIS Regulations – as opposed to the NIS Directive (the EU text) that includes these two sectors.

However, on 5th July 2018, the Bank of England (BoE), the Prudential Regulation Authority (PRA) and the Financial Conduct Authority (FCA) quickly reacted by publishing a Discussion Paper on the UK financial sector’s operational resilience.

This initiative gave Financial Services organisations until 5^th October to report on their exposure to risks and how they respond to outages.

One of the key aspects highlighted in this paper is the notion of cyber-tests. The structure of the paper clearly sets out the cyber-resilience aspects that will be tested by the regulators across the full incident lifecycle management: Preparation, Recovery, Governance and Communication.

Future of cyber-testing: the use of Red-Teaming by the regulators?

The notion of cyber-resilience testing has also been put forward in the new testing framework published by the European Central Bank (ECB) in May 2018: the Threat Intelligence-based Ethical Red Teaming (TIBER) EU Framework. The objective of this framework is to facilitate an approach towards intelligence-led tests which mimic the tactics, techniques and procedures of real hackers posing a genuine threat.

Even if the UK regulators are not obliged to implement this framework, it could give them some ideas to use these types of tests across all industries (like they did for the NIS Directive).

We expect that failing these tests will expose financial services organisations to sanctions in a similar vein as the Financial stress tests conducted in the last couple of years.

Cyber-resilience – Wavestone’s lessons learned

Organisations affected by major cyberattacks cannot continue to use their IT as normal and must fully or partly stop them to clean or rebuild them. Indeed, in some cases, attackers destroy critical parts of the IT infrastructure whilst in other cases, they penetrate and propagate the IT system for weeks to steal data or corrupt internal systems (Advanced Persistent Threat), thus causing a loss of confidence in the IT system.

For an organisation, to be cyber-resilient means being able to maintain vital activities in a downgraded mode in the event of a major cyberattack, while taking actions to quickly regain confidence in the IT system to be able to operate it as usual.

At Wavestone, we have developed strong expertise in supporting major cyber-crisis and cyber-resilience programmes. You will find below what we have learned on the topic, and in particular the 3 key aspects we recommend working on to become cyber-resilient.

Business Continuity Plans and Disaster Recovery Plans need to be reworked to face cyberthreats

Today’s Business Continuity Plans and Disaster Recovery Plans aim to respond to scenarios like a pandemic or a datacentre physical destruction, but many have been built without taking into account major cyberattack scenarios and the possible loss of confidence in the organisation’s IT that could result from such cyberattacks.

Within an organisation, ‘everyday’ IT and ‘backup/recovery’ IT systems are close in many ways, especially to facilitate their operability. As a result, in the event of a major cyberattack, the recovery systems will most likely be compromised at the same time as the ‘everyday’ IT systems, for 3 main reasons:

• Replication systems could copy the malware between the main IT estate and the recovery systems; or
• Attackers could exploit the administration infrastructure, common across both normal and recovery systems, to propagate within both; or
• Finally, even if the recovery systems are fully isolated, attackers could still exploit vulnerabilities present within both. Then, triggering your recovery systems would open the door for the malware to spread.

 1. Prepare to contain the attack when it occurs

Cyber-crises are specific:

• They last a long time (several weeks)
• They are difficult to understand (what have the attackers been able to do? For how long? What are the impacts? etc.)
• They involve third-parties who are often unprepared on the topic (lawyers, authorities, suppliers, clients, etc.)

Therefore, current crisis management processes must be supplemented to cater for the various cyber threat aspects. In particular, it is necessary to carry out the organisational and technical actions below to contain the attack when it occurs.

Organisational actions

• Identify the necessary people to call upon during a crisis (management, forensic experts, IT department, business continuity staff, HR, communication team, etc.) and specify their roles and responsibilities, as well as what needs to be done to allow them to be rapidly mobilised when necessary
  • For instance, during the crisis, the IT department will have to prioritise its actions between the investigation, the definition and implementation of the defence plan, and business-as-usual (BAU) operations
• Define processes that allow quick decisions from operational teams for threat containment (systems shutdown, floodgate activation, etc.), without waiting for a decision from the Crisis Management Team (CMT)
• Define appropriate processes to enable investigation activities and defence-plan-related activities in parallel, and to ensure 24/7 operations over a long time via rotations (logistics, HR, etc.)

Technical actions

• Identify backup communication tools outside of normal IT to safely manage the crisis (alternative mail, website to oversee the decisions, directory, etc.), as the usual communication tools may be unavailable or no longer trusted
• Make sure you have adequate investigation means to analyse and understand the attack (sufficient, safe and searchable logs, capability to analyse unknown malware, technical and functional cartography, detection processes based on business processes knowledge, etc.)
• Define floodgates in your network to be able to limit the attack propagation by isolating the most sensitive systems from those already compromised
• Make sure you have the right tools to protect the parts of the IT estate which are still safe once the threat has been isolated (quick patch deployment, etc.)

That being so, it is essential to regularly test the cyber-crisis management process via crisis exercises using ambitious and realistic scenarios.

2. Prepare to work without your IT

Business teams need to learn how to work in a downgraded mode without IT to simulate it being unavailable or untrustworthy for a few days or weeks. This may seem a bit extreme, but is what impacted organisations had to overcome in 2017, so better being prepared than sorry.

At least, business teams should ask themselves the following key questions to define processes and tools accordingly:

• Can we work with manual workarounds? (paper, cash, etc.)
  • If not, how can we interrupt our business activities in a controlled manner?
• What data do we need? (client contracts, contractors or suppliers lists, business data, etc.)
• What alternative tools do we need? (phones, applications like WhatsApp, applications like Gmail, etc.)

As for the cyber-crisis management process, these alternative ways of working must be tested to ensure the continuity of essential activities in the event of a major cyberattack

3. Prepare to rebuild your IT

If the cyberattack is a destructive one or important parts of the IT estate cannot be cleaned of a malware infection, there may be a need to rebuild some workstations, applications or infrastructure to maintain vital business activities. This must be anticipated, and processes and tools must be defined and implemented accordingly.

Regarding workstations, a user-friendly package (USB key and documentation) can be created to allow end-users to rebuild their workstations themselves. Besides, mobile backup servers can be used to restore users’ data (drop-shipping), in case the network bandwidth is not sufficient to remotely restore it for example.

Regarding applications and infrastructure, the key to success relies on two points:

• Rebuilding must be prioritised according to business needs, which must be defined beforehand; and
• Architectures must be standardised as much as possible to help automate and simplify their deployment in case they need to be rebuilt.

Do not forget standard cybersecurity measures, without which cyber-resilience cannot be reached

Implementing measures to address the 3 aforementioned cyber-resilience aspects will help you improve your cyber-resilience, but it is not sufficient. Efforts to do so must go hand-in-hand with efforts to ensure the appropriate protection and monitoring of your IT systems. Hopefully, this will help you avoid having to trigger these plans in the first place. So, keep up the hard work!

Cet article Cyber-resilience lessons learned: the latest UK developments est apparu en premier sur RiskInsight.

Wavestone has created the 2018 UK cybersecurity start-up radar to capture this environment and will be updating this on an annual basis.

A Thriving Start-up Environment

The overall UK start-up landscape is booming, and the UK is certainly a European hub for cybersecurity start-ups to establish themselves. We found that a large number of them came from abroad to set-up in the UK; from far and wide locations such as Hong Kong to Israel and the US. Throughout our research, we analysed a total of 158 cybersecurity start-ups, narrowing this down to a final 78 cybersecurity start-ups based on our selection criteria (detailed later). Notably, in comparison to last year, we amended our selection criteria to be more UK-focused; catering for any start-ups that may have potentially overlapped with Wavestone’s US and French cybersecurity start-up radars.

Areas of Specialisation

We chose the areas of specialisation ourselves and categorised the start-ups internally; as such, there is some element of subjection involved here. Our approach was to understand the essence of their offering and the field they are predominantly addressing. There was strong variety amongst the start-ups regarding their areas of specialisation, as the figures below show.

The top 3 most represented areas were:

1. Identity & Access Management (18%)
2. Data Security & Collaboration (12%)
3. Application Security (9%)

Conversely, the least represented areas were Physical Security, Anonymisation and Deception (each scoring 1%).

Identity Access Management and Data Security & Collaboration may have taken the top two spots given that they are both broad categories. Interestingly, some cloud security providers may have fallen into the two aforementioned categories and this may explain why there is a surprisingly low number of start-ups specialising in ‘Cloud Security’ (only 3%).

Overall, however, the above highlights that the cybersecurity start-ups are well-spread across all other categories; indicating that the market is healthy with a wide range of cybersecurity topics drawing entrepreneurial interest.

Start-up distribution across the UK?

Expectedly, the majority of these start-ups (65%) are London-based; perhaps explained by the growing demand from the UK’s financial services sector to secure their IT systems in the wake of several cyber-attacks over the last 3 years, such as the two-day DDoS attack on Lloyd’s Banking Group in January 2017.

Outside of London however, cybersecurity start-ups are looking to build out their operations from Research hubs across the UK. Cambridge was the second most popular location for start-ups in our radar (5%); a hotspot due to the strong pool of university students and knowledge-sharing, not to mention lower operating costs in comparison to London.

Other notable cities include Belfast (4%) and Manchester (3%); attractive candidates for young firms as these locations are hubs for growth and offer rich culture. Only one start-up located in Cheltenham, which is surprising given that this is the GCHQ’s primary location.

Start-up development

To gauge a sense of maturity, we looked at both foundation year and number of employees in parallel. As expected, our research found that the majority of our start-ups have 10 employees or less (62%) showing they are still very young and fittingly, most of these were also founded in the last 4 years. 2015 was the year that most of our start-ups (28%) were founded, with slightly more of the remaining population being established post-2015. This spike demonstrates the gathering momentum in the cybersecurity industry over recent years (particularly with cyber-attacks gaining more media coverage and increased demand for cybersecurity solutions amongst CIO agendas). In the last year, perhaps we haven’t seen as many start-ups because their solutions are not mature enough to be visible in the market yet.

Unsurprisingly, the 4 start-ups founded this year all have less than 10 employees each and it is not abnormal for these start-ups to remain small in employee size; for example, of those founded between 2012-2014 collectively, 10 out of 27 start-ups still only have 10 or less employees.

Support for Start-Ups

Numerous accelerators and incubators support the UK start-up ecosystem and play a critical role in its development by providing mentoring, courses and networking opportunities amongst other initiatives:

Alongside these accelerators, it has been encouraging to see the UK Government casting more attention to the growing cybersecurity sector, not least driven by serious breaches to UK infrastructure e.g. the WannaCry attack on the NHS last year. In March this year for example, the Department for International Trade (DIT) launched a new Cybersecurity Export Strategy detailing how the Government aims to support UK cybersecurity firms in protecting overseas enterprises. This initiative, alongside others such as the National Cybersecurity Centre (NCSC), are all part of the ‘National Cyber Security Strategy 2016 to 2021’, which was launched by the UK Government to outline how they will protect UK businesses through £1.9bn of investment into cybersecurity. These programmes combined are a real driving force behind the development of the UK cybersecurity sector and present a wealth of opportunities for start-ups to benefit from.

Cet article 2018 UK Cybersecurity Start-up Radar est apparu en premier sur RiskInsight.