Brewing Cybersecurity Insights

Author: CyberSec_Cafe (Page 3 of 4)

The secrets to Master Key Management in Cloud Encryption

A Comprehensive Guide in Light of Recent Security Breaches

Introduction

In the world of cybersecurity, a recent event serves as a grim reminder of the crucial role that key management plays in cloud encryption. On July 11, 2023, Microsoft reported a severe breach where China-backed hackers gained unauthorized access to several email inboxes, including those of prominent federal government agencies. The attack was facilitated by Microsoft’s loss of control over its own keys, underscoring the dire consequences of inadequate key management. In light of this incident, this article aims to provide a comprehensive understanding of key management in cloud encryption, underscoring the need for robust strategies to mitigate such cybersecurity threats.

In the realm of cloud services, securing sensitive data remains a critical concern for businesses worldwide. At the heart of this security is encryption, which renders data unintelligible without the appropriate decryption key. Consequently, managing these keys appropriately is of paramount importance. In this piece, we’ll delve into the nuanced world of key management, investigate the varying options provided by cloud service providers, and examine performance considerations, particularly for transaction processing.

The Importance of Key Management in Cloud Encryption

Encryption serves as the bedrock of data security within the cloud, translating readable data into a coded form decipherable only with the correct decryption key. Thus, the proper management of these keys becomes critical in maintaining data security.

Poor key management can lead to unauthorized access to encrypted data or, on the flip side, permanent loss of access to data if keys are lost or corrupted. Therefore, key management is not just an optional add-on but an essential part of an organization’s overall data security strategy.

Key Management Options in the Cloud

When it comes to managing encryption keys in the cloud, providers typically four main strategies can be used, each with its unique benefits and considerations:

  1. Cloud Provider Managed Keys: The cloud provider generates and manages the keys, a simple approach that offers the least control over the keys. However, it’s the most cost-effective, as there are no additional charges for key management.
  2. Bring Your Own Key (BYOK)Customer-Managed Keys in Cloud Provider’s Hardware Security Module: Here, the client generate and manage their own own keys but store them in the cloud provider’s Hardware Security Module (HSM). This solution offers more control over the keys and guarantees secure storage and requires the use of the provider’s HSM services.
  3. Customer Supplied and Managed Keys (CYOK) – Customer Managed Keys not exposed in Cloud: In this scenario, the end-user generates their keys, which are never exposed to cloud providers, even if stored and used in the cloud. The end-user controls the full key lifecycle and can instantly revoke keys at any time. These keys can reside in a protected virtual node within the cloud or a hybrid environment in an on-premise data center.
  4. Hold Your Own Key (HYOK)Customer-Managed Keys in Customer’s HSM: the client generate, manage, and store the keys in their own HSM, offering the highest level of control. This option offers the highest level of control but also requires complete responsibility for the security and resilience of the HSM infrastructure. It can be the most costly due to the overhead of maintaining an HSM infrastructure.

Deep Dive into Performance Considerations

When considering HYOK , a significant factor to take into account is the potential impact on performance, particularly when handling numerous transactions. On-premise HSMs can introduce latency due to the need for encryption/decryption requests to travel to and from the HSM.

If the demand for encryption-related operations is high and frequent, the latency could introduce bottlenecks affecting the performance of transaction processing.

However, if an organization prioritizes control and security over cost and/or performance and has the resources to manage and secure the HSM infrastructure properly, this options can be the most appropriate.

Key Considerations

In selecting your key management strategy, consider the following:

  • Cost: Control level usually correlates with cost; HYOK offers maximum control but at higher costs.
  • Performance: Encryption and decryption operations can impact application performance. Depending on the option chosen, you may need to ensure adequate resources to guarantee performance.
  • Confidentiality: With cloud provider-managed keys, the provider potentially can access your keys. For utmost confidentiality, managing keys in your own HSM is advisable.
  • Jurisdiction: For regulations like GDPR, it’s crucial to know where your keys are stored and managed. Using your own HSM provides complete control and transparency over key location.
  • Operational Complexity: Managing your own keys introduces added operational complexity, requiring dedicated expertise in cryptographic key management.

Additionally some cloud providers might not be interested in helping the client keeping encrypted data in their systems

Conclusion

Choosing an appropriate key management strategy involves careful consideration of cost, performance, control, confidentiality, jurisdictional compliance, and operational complexity. Cloud Provider Managed Keys, BYOK, CYOK, and HYOK all offer different degrees of these factors.

The key is finding a balance that meets your organization’s specific needs and resources. With a clear understanding of the available options, you can make an informed decision that not only safeguards your data but also aligns with your operational capabilities and business objectives.

The Rising Stakes for Cybersecurity Accountability

An Analysis of the SEC notice to SolarWinds CISO and CFO

The Rising Stakes for Cybersecurity Accountability
Image by Bing Image Creator

The cybersecurity landscape is witnessing an unprecedented shift. The recent move by the U.S. Securities and Exchange Commission (SEC) to issue Wells Notices to the CFO and CISO of SolarWinds is a bellwether of this change.

A Wells Notice is a communication from the SEC indicating that it has made a preliminary decision to recommend enforcement action against the recipient, although it is not a formal charge of wrongdoing or a final determination of violation​.

The SEC’s decision suggests a new emphasis on individual accountability within organizations for cybersecurity management and incident disclosure. However, this development also shines a light on a complex challenge: the multifaceted and collective nature of cybersecurity.

Why is this significant?

Firstly, it demonstrates an increased scrutiny of companies’ responses to cyberattacks. In this case, the SEC alleges that SolarWinds violated certain provisions of U.S. federal securities laws in its cybersecurity disclosures, public statements, and internal controls following the cyberattack in 2020, which affected thousands of customers globally​.

Secondly, this is unusual because a Wells Notice is typically sent to a company itself, not individuals within the company. Wells Notice are usually reserved for CEOs or CFOs in cases of Ponzi schemes, accounting fraud, or market manipulation.

This development suggests that the SEC might be moving towards holding individuals, particularly CISOs, more accountable for managing cybersecurity and disclosing cyber incidents. One possible violation that a CISO might commit is a failure to disclose material information, such as failing to disclose the gravity of an incident or failing to do so in a timely manner. This is a trend confirmed by the the previous conviction of Uber’s CISO and his sentence.

However, some cybersecurity professionals argue that attributing blame solely to the CISO or CFO might not always be fair or accurate, because…

… Cybersecurity management typically involves various stakeholders

In today’s digitized world, a Chief Information Security Officer (CISO) plays an essential role far beyond just implementing and managing security measures. The CISO’s duty also involves making other CXOs accountable for their part in cybersecurity. This includes ensuring that for instance that:

  • HR make sure that the resources completes the necessary security training,
  • Risk Management keeps cyber risks within defined thresholds,
  • Finance aligns the security budget with mitigation strategies (that in turn are based on the organization strategies and risks),
  • IT oversees the secure development and maintenance of applications.

But what happens when risk acceptance is chosen as the path forward?

If a CXO or the CEO decides to accept a risk, they should be accountable for that decision. It is crucial that such risk acceptance is well-documented and tracked.

I assume that in SolarWind and Uber incidents top management might have wanted to take a risk acceptance decision but didn’t want it to be documented (I assume because I personally saw this happening).

Conversely, a too accommodating CISO who fails to enforce necessary security measures might find themselves, and put their organization, in the firing line.

The Challenge of Execution

An important yet often overlooked aspect of cybersecurity is the actual execution of security measures. Even when a CISO or security leader gives orders for security actions, the implementation may not always follow through, especially if the person responsible isn’t part of the cybersecurity team. These orders may go unfulfilled due to conflicting priorities, and performance objectives that do not include security are not helping.

This state of affairs points to the need for organizations to align their objectives across departments and ensure that security is a shared priority. Without this alignment, the cybersecurity of the organization remains fractured and vulnerable.

No matter how robust the cybersecurity measures are, it’s impossible to prevent all cyberattacks. I think that the sophistication of the SolarWind attack is a great example of that.

Risk mitigation doesn’t aim for 100% security—residual risks are inevitable. Therefore, managing risks effectively within acceptable thresholds becomes the primary goal. This goal underlines the need for comprehensive risk management strategies that involve all stakeholders in an organization. Let’s not forget that security is just one of many goals of an organization, which also has to do business, and too much security might make the company non-competitive.

The Road Ahead

The SEC’s move towards increased individual accountability in cybersecurity could have profound implications for how organizations manage cybersecurity risks. However, it’s essential for organizations (and governments) to remember that cybersecurity is a collective responsibility. It requires coordinated efforts across departments and roles.

This reality makes the role of the CISO even more critical. They need to bridge the gap between different stakeholders and ensure a holistic approach to cybersecurity. While the SEC’s move might bring with it new challenges and pressures, it also presents an opportunity: to reaffirm the collective responsibility of cybersecurity, reinforcing that it is a task that falls on everyone’s shoulders within an organization.

A persisting question I have is: what should a CISO do if the CEO orders them not to disclose material information and to avoid documenting this decision?

A CISO who blindly follows such orders risks becoming a Scapegoat Officer, serving as a convenient fall guy in the aftermath of a cyber incident rather than actively improving the security posture of their organization. And he/she might not be inclined to do so if they will be put behind bars for that.

That’s a real pickle, so a second question arise: what a government should do to avoid it?

Maybe foresee a sort of Whistle-blowing channel for CISOs that would guarantee a criminal shield in case of situations like the SolarWind and Uber ones?

Last question, what would happen if the company uses a vCISO or a CISO-as-a-Service?

Navigating this new landscape will be challenging, but with clear communication, well-defined roles, and a shared commitment to security, organizations can rise to the occasion. It’s not just about preventing the next big cyberattack—it’s about fostering a culture of shared responsibility and vigilance that permeates every level of the organization. In this era of increasing cyber threats, there is no other way forward.

The Human Element in Cybersecurity

Moving Beyond Technology

Human Element
Image by Bing Image Creator

The Human Element – Introduction:

When it comes to cybersecurity, most people tend to think it’s all about technology. But guess what? It’s time to break that misconception. In today’s world, cyber threats the weakest link in the security chain is the human element.

You see, we may have fancy technologies, but there’s no magic bullet (despite what many vendors promise). No matter how much we invest in technology, we can still fall prey to cybercriminals who know just how to exploit our human nature.

The Conti ransomware gang hit the nail on the head last year when they said, “we also need to focus on the human part of our attacks. Our targets invest millions of dollars in security technologies, but they often overlook the human element. We will continue to exploit this weakness to our advantage.”” It’s a wake-up call to understand that in the traditional triad of People, Processes, and Technology, People are (and have been in probably the last 10 years) the center stage in cybersecurity.

So, buckle up and keep reading as we dive into the role of the human factor in cyber attacks.

The Exploitation of Human Vulnerabilities:

Cybercriminals are crafty. They know that humans are easier to manipulate than sophisticated security technologies. They also look for a ROI on their investments, so they will use whatever is the cheaper approach to reach their goal. So, they use psychological tricks like phishing and social engineering to exploit our weaknesses and gain unauthorized access to sensitive information. They send convincing email scams, impersonate trusted entities, and even dig up personal details from social media to trick us into revealing confidential data or compromising system security.

Still think that cybersecurity is all about fancy technology?

You took a look at the latest latest ENISA Threat Landscape. You saw that the top threats include ransomware and malware—definitely techie stuff. But guess who unwittingly lets those threats in? Yep, it’s people.

Now let me tell you, the Ponemon Institute’s Cost of Data Breach report is an eye-opener. In their “Initial attack vectors” section, they highlight the prevalence and cost of human-related attack vectors. Stolen or compromised credentials accounted for 19% of breaches, costing an average of $4.50 million. Phishing, at 16% of breaches, topped the list as the costliest initial attack vector, with an average cost of $4.91 million. Business email compromise was another initial vector among cyber attackers.

If you look closely, you’ll notice that every issue, even seemingly technical ones like “Vulnerability in third-party software,” ultimately comes down to human error. After all, who coded the software with the vulnerability or who didn’t define or apply a patching process? That’s right, a human.

Moving Towards a People-Centric Approach:

So, what can we do about it? Well, it’s time for organizations to start adopting a people-centric approach to cybersecurity. My recipe consist in building a “Cyber Culture”! This means understand what are the Cyber behaviors we want to influence, providing comprehensive training programs to raise cybersecurity awareness among employees and promoting a culture of vigilance and responsible behavior. We gotta teach everyday users about common cyber threats, show them how to spot suspicious activities, and encourage good practices like creating strong passwords and keeping software up to date.

But it’s not just about training. Organizations need to share real-world examples of cyber attacks, so people can see the real risks out there. By making everyone feel responsible for cybersecurity, we turn our workforce into a first line of defense against cyber threats.

And here’s a secret: investing in the human factor is not only cheaper, but it’s also way more effective than splurging on fancy technology. I mean, sure, we still need the right tools, but without a strong Cyber Culture, we’re like a castle with a moat but no guards. It just doesn’t work! I will write an article on this topic in the future.

So why isn’t a a People-Centric approach that widespread?

Many people still think that cybersecurity is all about technology. They believe it’s a technical issue that only (nerdy) IT folks (with glasses and a hoodie) can handle. The problem is that cybersecurity specialists often are really technical to start with so they neglect the crucial human elements.

And here’s another kicker: reporting lines within organizations often make things worse. Cybersecurity teams end up aligned with IT departments, who are mainly focused only on technical risks!

I know I’m digressing this is another topic: the need of having an effective, diverse and multidisciplinary Cyber team.

But the truth is, investing in Cyber Culture, in our people, is the key to success. It’s not only more cost-effective, but it’s also more impactful in preventing and mitigating cyber threats. So I think it’s time to break the cycle!

Conclusion:

it’s time we realized that cybersecurity is not just about technology. People play a crucial role, and cybercriminals know it. By adopting a people-centric approach, building a strong Cyber Culture, and empowering employees to be active defenders, organizations can level up their defense against cyber threats.

So, let’s remember that we’re not alone in this fight. It’s not just about fancy tech; it’s about us, the people. Together, we can create a safer digital world. Let’s do this!

Unveiling the Risk Landscape of LLMs

A Comprehensive approach proposal

Risk Landscape of LLM
Created with Bing Image Creator

Greetings, readers! Welcome back to our exploration of LLM (Large Language Models) security risks. In my previous posts (here and here), I discussed the significance of understanding these risks. That’s why I am excited to share my participation in the creation of the OWASP Top 10 Risk for Large Language Model Applications 😊.

In this article, we will delve into the challenges involved in defining an approach to create the Top 10 LLM security risk list and propose a holistic approach to address them.

The Challenges in Defining a Top 10 LLM Security Risk List

As we embark on this endeavor, we encounter several challenges that need to be overcome:

  1. Evolving Landscape: LLMs are rapidly evolving, with new models (including Open ones with no restrictions) and attack techniques emerging. Keeping the evaluation comprehensive to address emerging risks is challenging but necessary.
  2. Complexity and Interdependencies: LLMs involve various components, including training data, algorithms, infrastructure, and user interactions. Understanding their interdependencies and how risks propagate across them requires careful analysis. Some components are already covered by other Top 10s but they might be so relevant that we might want to include them
  3. Lack of Standardization: Inconsistencies in terminology and definitions related to LLM security risks can lead to inconsistencies in risk assessment and mitigation. Establishing standardized language and frameworks is vital and luckily OWASP will help a lot in this. A couple of examples below:
    • I had a discussion about Intellectual Property Theft. I wrongly assumed that we were speaking only the theft of the LLM model itself, but if we think about it there are other king of IP theft, e.g., the weights are intellectual property, or if some users provide IP to the LLM, the LLM will learn from that and might provide the IP to the next users. As I said I didn’t consider those as for me those were privacy risks… but these are also ML risks
    • We had discussions on how we should call the “hallucination” risk (e.g., is this term humanizing LLMs? Shuldn’t something as “Confabulation” be better? Maybe, but hallucination is already LLM Jargon).
  4. Multidimensional Risks: LLM risks encompass technical, ethical, legal, and societal aspects. Incorporating these perspectives and achieving a holistic understanding is essential.
  5. Risk Prioritization: Determining the significance of each risk and prioritizing them within the Top 10 list is complex. Professional judgment and a thorough assessment are needed.
  6. Balance of Granularity: Striking the right balance between granularity and practicality is crucial. The Top 10 list should be concise, understandable, and actionable, while capturing the breadth and depth of LLM security risks.

Addressing the Challenges with TARA

“Necessity makes the method” used to say one of my old bosses, and to tackle these challenges, I propose adopting a TARA (Threat Analysis and Risk Assessment) method, which involves identifying potential threats, analyzing their likelihood and impact, and evaluating associated risks.

First Step: Threat Modeling

We start conducting a comprehensive threat modelling exercise, defining threat categories specific to LLMs and documenting potential threats within each category.

Below you will find my proposal of threat list, it is not supposed to be 100% correct, just to give an idea on how it would look like. To do so I used OWASP v0.1, Adam AI centered Top 10 some of the Cybersec risks and ML risks from this super insightful article.

Category Threats Sub-Threat 
LLM-specific Prompt Injection Direct Prompt Injection 
Second Order Injection 
Cross-content injections 
Machine Learning Training-Time Attacks Training Data Poisoning 
Byzantine attacks 
Decision-Time Attacks Inference 
Evasion Attacks  ???
Oracle Attacks Extraction 
Inversion 
Membership Inference 
Model Theft Model Theft
Surrogate Model
Statistical Attack Vectors Bias  Drift 
Model Hijacking Attacks Backdoors 
Trojanized models 
User specific Overreliance on LLM-generated ContentHallucination
Bias
Inexplicability
Operational  ???Inadequate AI Alignment
Application /  
Infrastructure 
Insecure development Inadequate Sandboxing 
Improper Error Handling
Insecure deploymentUnauthorized Code Execution 
SSRF Vulnerabilities
Insufficient Access Controls
Personal Data /  
Intellectual Property 
 ???Data Leakage
IP Theft
A proposal of LLM Threats

To be more accurate, this exercise leans more towards threat identification rather than threat modelling.

Please note that I’m not sure where all the sub-threats should be. For instance an ML threat might be the root cause of the existence of some User specific or Personal Data/IP threats…

The following TARA Steps

The next steps would be:

  1. Risk Evaluation: Estimate the likelihood and impact of each identified threat, considering various perspectives and dimensions. Combine these factors to calculate the overall risk level associated with each threat.
  2. Risk Prioritization: Prioritize risks based on their significance and impact, using professional judgment and a holistic perspective to choose the Top 10.
  3. Mitigation Strategies: Define appropriate mitigation and prevention strategies to address the identified risks effectively.

Those phases are all straightforward, the only difficult part could be understanding the impact. What angle do we need to consider? For an organization of course many of those threats could result in data breaches, financial losses, reputational damage, legal implications, etc. What if we consider a non-enterprise end-user? And the LLM owner? E.g., the latter would be the only one that wants to avoid model theft…

Conclusion

LLMs are at the forefront of technological advancement, and understanding their risks is paramount for secure adoption. By adopting a comprehensive approach like TARA, we can identify, assess, and mitigate these risks more effectively.

Collaboration, standardization, and a multidisciplinary perspective are key to success in this endeavor. Let’s work together to create a safer LLM landscape and pave the way for responsible and secure deployment.

Join me for future articles as we explore LLM security risks and discuss practical mitigation strategies.

OWASP vs. Cybersec.Café’s LLM Top Security Risks

A Follow-Up Comparative Analysis

LLM Top Security Risks
Created with Bing Image Creator

Following our previous exploration of Large Language Models’ (LLMs) security risks, I am now presenting a comparative analysis of the risks highlighted by Cybersec.Café and those identified by OWASP (Open Web Application Security Project). OWASP is a renowned authority in web application security and has recently published a preliminary list of LLM security risk.

LLM Top Security Risks Comparative Analysis

1. Jailbreaking

This corresponds to several risks in OWASP’s list: LLM03:2023 – Inadequate Sandboxing, LLM04:2023 – Unauthorized Code Execution, LLM05:2023 – SSRF Vulnerabilities, LLM08:2023 – Insufficient Access Controls, and LLM09:2023 – Improper Error Handling.

In my perspective, Jailbreaking refers to the process of gaining unauthorized access to and control over an LLM’s underlying systems or processes, while OWASP risks might pertain more to the system or application underpinning the LLM rather than the LLM itself. While jailbreaking could serve as an entry point for exploiting these OWASP risks, the mitigation strategies may not be fully effective in all cases.

By articulating these risks separately, OWASP’s approach might help define individual mitigation actions.

2. (Direct) Prompt injection, 3. Second-order injections

These risks directly align with OWASP’s LLM01:2023 – Prompt Injections, although OWASP’s category encompasses all forms of prompt injections.

4. Data Poisoning

This directly aligns with OWASP’s LLM10:2023 – Training Data Poisoning.

5. Misinformation

This risk somewhat corresponds to OWASP’s LLM06:2023 – Overreliance on LLM-generated Content, especially in scenarios where overreliance results in misinformation. However, OWASP’s category includes other potential issues, such as bias, making it more comprehensive.

6. Malicious content generation

This risk intersects with OWASP’s LLM07:2023 – Inadequate AI Alignment. The link might seem tenuous, but the principle remains that an LLM’s use case should not be creating malicious content.

7. Weaponization, 8. LLM-delivered attacks

These risks overlap with OWASP’s LLM04:2023 – Unauthorized Code Execution and LLM07:2023 – Inadequate AI Alignment. These risks underscore the potential for LLMs to be exploited for malicious purposes, be it coding malware or delivering attacks.

9. Abuse of vertical LLM APIs

This risk relates to OWASP’s LLM07:2023 – Inadequate AI Alignment and LLM08:2023 – Insufficient Access Controls. Poor AI alignment could potentially lead to misuse of the LLM, and similarly, poor access control could result in unauthorized actions.

10. Privacy and Data Leakage

This risk directly corresponds to OWASP’s LLM02:2023 – Data Leakage.

Conclusion

In creating this top 10 and comparing it with OWASP’s list, I observed that the key differences lie in the granularity and standardization of terminology.

The field of LLM security is still relatively nascent, and there is a noticeable need for standardization of terms. This comparison has shed light on this fact.

I hope that OWASP’s risk list will bring the critical security considerations for LLMs into sharper focus, laying a solid foundation for further discussions and the development of security measures in this rapidly evolving technology sphere.

The Top 10 Large Language Models Security Risks

Understanding the Top 10 Security Risks Associated with Large Language Models (LLMs)

Top 10 Large Language Models Security Risks
Image by Bing Image Creator

Introduction

Large Language Models (LLMs) have revolutionized the field of artificial intelligence and natural language processing, but with great power comes great responsibility. As LLMs become increasingly prevalent, it’s essential to understand the potential security risks they pose.

In light of OWASP’s recent announcement of the OWASP Top 10 Risk for Large Language Model Applications, this article aims to explore my perspective on the top 10 security risks associated with LLMs. I am eager to compare and contrast these risks with the ones OWASP will publish.

Cybersec.Cafè Top 10 Large Language Models Security Risks

  1. Jailbreaking: Bypassing the security measures of an LLM to gain unauthorized control and exploit it for malicious purposes.
  2. Prompt injection: Crafting prompts to influence the model’s output, which can lead to biased, offensive, or harmful text generation.
  3. Second-order injections: Advanced prompt injection techniques, where the prompt itself is generated by an LLM, making it harder to detect and prevent attacks. Note: I’m not considering cross-content injections (a type of prompt injection where the prompt is generated in one context and then used to generate text in another context – this can be used to generate text that is relevant to the first context but harmful in the second context) as I consider still as in between of both risk 2 and 3
  4. Data poisoning: Injecting malicious data into the training dataset, resulting in biased or harmful outputs. Rigorous validation and monitoring are crucial to mitigate this risk. This is actually a Machine Learning (ML) risk that extend to LLMs being that their training is ML based.
  5. Misinformation: Unintentional contribution to the spread of misinformation or support for creating misinformation campaigns.
  6. Malicious content generation: Misusing LLMs to generate persuasive or believable text for phishing or social engineering attacks.
  7. Weaponization: Misusing LLMs to support coding malware or potentially even for malware detection evasion (still a theoretical threat) by generating malware code that evades traditional endpoint detection and response scanners. For example, an LLM could be used to generate malware code that is not detected by traditional Endpoint Detection and Response scanners as the code is generated by an LLM that provides it via API.
  8. LLM-delivered attacks: Using LLMs to deceive users and obtain sensitive information or launch cyber attacks. For example, an LLM could be used to ask a user for sensitive information such as their passwords or credit card number.
  9. Abuse of vertical LLM APIs: Exploiting LLMs for purposes outside their intended use cases, potentially undermining the intended business model.
  10. Privacy: LLMs are trained on massive datasets that contain also personal information, raising privacy concerns if the models generate text like the confidential data it was trained from. This happens for instance with Inference Attacks or Model Inversion Attacks these attacks attempt to infer or recreate information about the training data from the outputs of an ML model.

Some other thoughts

Conclusion

While the risks associated with LLMs may seem challenging, we don’t know yet if they are insurmountable. As of today, we still lack comprehensive solutions to mitigate most of these risks compared to other security domains like applications and mobile devices. Additionally, due to the “black box” nature of LLMs, understanding their inner workings presents challenges in determining the appropriate security measures to adopt. Furthermore, regulatory frameworks surrounding LLM use are still evolving, as discussed in my geopolitical analysis of the ChatGPT block in Italy.

LLM security contains a multitude of unknown unknowns, and it necessitates further research and mitigation strategies to effectively safeguard against these risks. Awareness serves as the critical first step towards achieving effective cybersecurity if it will be ever possible to reach it.

Recommended Readings

To delve deeper into the topic, I recommend reading the following insightful resources:

  • https://www.wired.com/story/chatgpt-jailbreak-generative-ai-hacking/
  • https://themathcompany.com/blog/data-poisoning-and-its-impact-on-the-ai-ecosystem
  • https://spectrum.ieee.org/ai-cybersecurity-data-poisoning
  • https://www.semianalysis.com/p/google-we-have-no-moat-and-neither
  • https://ambcrypto.com/heres-how-to-jailbreak-chatgpt-with-the-top-4-methods-5/
  • https://www.techopedia.com/what-is-jailbreaking-in-ai-models-like-chatgpt
  • https://www.theregister.com/2023/04/26/simon_willison_prompt_injection/
  • https://blogs.itemis.com/en/model-attacks-exploits-and-vulnerabilities
  • https://research.nccgroup.com/2022/12/05/exploring-prompt-injection-attacks/
  • https://hiddenlayer.com/research/the-dark-side-of-large-language-models/
  • https://hiddenlayer.com/research/the-dark-side-of-large-language-models-2/
  • https://embracethered.com/blog/posts/2023/ai-injections-direct-and-indirect-prompt-injection-basics/
  • https://embracethered.com/blog/posts/2023/ai-injections-threats-context-matters/
  • https://www.mufeedvh.com/llm-security/

Relying on Security-by-Luck

The Interplay of Risk, Investment, and… Luck in Cybersecurity

Security-by-Luck
Photo by Djalma Paiva Armelin from Pexels

Last weekend, I came across a LinkedIn post illustrating how numerous companies were breached despite having SOC2, ISO 27001, and PCI-DSS certifications. This observation prompted me to reflect.

Initially, my thought was that there isn’t a direct correlation. The data set is rather small and doesn’t account for all the certified companies that have avoided breaches. Furthermore, certification is a form of assurance that some level of security is in place, signaling to potential attackers that there is valuable data worth protecting.

In the cybersecurity realm, we frequently emphasize robust defense mechanisms, proactive risk assessments, and constant vigilance. Today, however, I want to navigate less charted territory: “security-by-luck”.

What do you mean with Security-by-Luck?

My definition of “Security-by-luck” would be the situation where a company, despite having weak or inadequate security measures, remains unbreached due to factors outside its control, such as the attackers’ choices, capabilities, or sheer chance.

To clarify, I’m not endorsing this as a strategic approach – that would be reckless. Rather, I aim to highlight a crucial facet of cybersecurity – the constant interplay of risk, investment, and a dose of luck.

In a previous article, I discussed on the challenge of defining ‘how much security is enough’. No matter how much an organization invests in security, the threat of an attack persists. Conversely, not all lightly-defended organizations will suffer breaches, too lightly defended (even if those that are inadequately defended become low-hanging fruit for cybercriminals). However, over-investment in security isn’t the solution either, as organizations have other business objectives to meet. So, the question arises, where do we draw the line?

I’m not suggesting that companies should stop investing in cybersecurity and merely hope for the best. Instead, I want to stress the importance of making calculated risks.

To illustrate this, consider four hypothetical companies, each investing differently in cybersecurity…

The contenders:

  • Company A: Does the bare minimum for security (e.g., has an antivirus installed)
  • Company B: Complies with statutory requirements and uses common sense
  • Company C: Adheres to a cybersecurity standard and has obtained certification (like SOC 2, ISO 27001, PCI-DSS, HITRUST, etc.)
  • Company D: Follows all major best practices and has adopted bleeding-edge security solutions

Each of these companies, regardless of their investment level, can either be breached or remain secure. Here’s how:

Vulnerabilities-based Attacks:

  • A vulnerability in their system gets exploited – Company A gets breached.
  • Company B, which patches vulnerabilities quarterly, gets breached when an attacker exploits a flaw within the time window before it gets patched.
  • Even Company C, which patches vulnerabilities monthly, gets hacked, as the attackers were quicker on their feet.
  • Company D has no known unpatched vulnerabilities (a near impossibility in real life, but let’s go with it). However, there’s a zero-day vulnerability that they aren’t aware of (I know this is the definition of zero day). An attacker discovers and exploits it – Company D gets breached.

Let’s assume, for a moment, that all these companies understand this risk and decide to have all vulnerabilities patched (again a near impossibility) and are lucky there aren’t any unexploited zero-day vulnerabilities. You might think they’re safe. But what if an attacker targets their people instead?

People-based Attacks:

  • An attacker successfully executes a phishing attack on Company A, leading to a breach.
  • Despite having good email security and having conducted a phishing simulation last year, Company B falls prey to a successful social engineering attack.
  • Company C suffers a sophisticated MFA fatigue attack and gets breached.
  • In Company D, an attacker bribes an employee to gain access to the system (including credentials and MFA, as seen in the Lapsus$ attacks last year).

Even if the organization decide to invest in a solid cyber culture and luckily their employees are equipped with strong ethics to resist such attempts, are the potential threats truly over?

Unfortunately, no, the threats aren’t over. They are susceptible to…

Supply Chain Attacks:

The attack surface extends to vendors, giving birth to a new cycle of vulnerabilities and people-based attacks. Hence, even Company D could harbor cybersecurity points of failure within their supply chain.

Luck is Not a Strategy

In essence, cybersecurity isn’t merely about investment levels; it’s also about the complex interplay of factors that contribute to a company’s overall risk profile. Even the most secure organization cannot completely rule out the possibility of a breach. Given the dynamic nature of the landscape, absolute security is a virtual impossibility, making a small element of ‘luck’ an undeniable part of the equation.

Regrettably, many companies have relied solely on this ‘luck’ factor for so long that they’ve now become easy targets.

‘Security-by-Luck’ should not be a strategy in itself, but understanding its role in the broader cybersecurity framework is essential. The goal should always be to optimize investment, maintain a robust defense mechanism, foster employee awareness, and devise sound strategies to mitigate potential risks, including supply chain risks. This involves striking a balance, understanding that no solution offers 100% protection, and ensuring readiness to respond effectively (by having incident response plans and exercises conducted) if or when a breach occurs by conducting regular incident response plans and exercises.

Conclusion

In conclusion, while we can’t depend entirely on luck, or as the Cybersecurity community usually call it, the residual-risk, acknowledging its existence, could make us more attuned to the realities of the ever-evolving cybersecurity landscape. The presence of residual risk is an undeniable part of cybersecurity, and acknowledging without relying on it might encourage a more realistic approach towards cybersecurity strategy and implementation.

The Pros and Cons of vCISO and CISO-as-a-Service

Navigating the Challenges of Cybersecurity Leadership

The Pros and Cons of vCISO and CISO-as-a-Service
Image by Bing Images Creator

Introduction

Virtual CISO – vCISO and CISO-as-a-Service are emerging as popular options for organizations looking to strengthen their cybersecurity posture without hiring a full-time CISO. Sorry for the over-simplification but it would basically be a part-time Security Expert acting as a CISO. While these services offer certain benefits, they also come with potential drawbacks. In this article, we’ll explore the advantages and challenges of vCISO and CISO-as-a-Service and discuss how to find the right balance.

The Benefits of vCISO and CISO-as-a-Service

  1. Access to expertise: vCISO and CISO-as-a-Service can provide organizations with the cybersecurity expertise they might not have in-house. This can be especially valuable for smaller companies or those just starting their security journey. Please note that security professionals are a hot commodity, and organizations should ensure they are using resources with the right skills. For example, someone who configured firewalls might be considered a (Network) Security Expert, but will they be the right expert to define a long term Cybersecurity strategy?
  2. Temporary solution: vCISO and CISO-as-a-Service can serve as a temporary measure to fill the gap in cybersecurity leadership, especially when organizations face difficulties in hiring a full-time CISO or during transitional periods.
  3. Flexibility: vCISO and CISO-as-a-Service offer flexibility for organizations experiencing transition or growth. These services can be scaled up or down according to the organization’s needs, providing a tailored solution to their cybersecurity challenges.

The Limitations of vCISO and CISO-as-a-Service

  1. Accountability: While vCISOs and CISO-as-a-Service providers hold a “C” in their title, they may not have the same level of accountability as a full-time, in-house CISO. Organizations looking to meet ESG (Environmental, Social, and Governance) requirements may need a more accountable figure in the role. In other words, did you ever see a vCFO or a CFO-as-a-Service?
  2. Integration, Authority, and Long-term Strategy: vCISOs and CISO-as-a-Service providers may not have the same level of authority within an organization, potentially limiting their ability to effectively integrate with various departments and functions. Moreover, due to the limited length of their contract and insufficient knowledge of the company (technology, processes, people, and culture), they may struggle to plan and implement a comprehensive, long-term security strategy, leading to a focus on quick wins instead.
  3. Conflict of Interest: If a vCISO or CISO-as-a-Service provider is affiliated with a company that sells or provides cybersecurity services, there may be a conflict of interest. This can result in a lack of neutrality, which could affect their advice and recommendations and even questionable decision-making. Especially because they are not accountable (see point 1, jointly with this point it is a potential recipe for disaster). However affiliation it is not necessary a bad thing as it would allow to involve specific vertical competencies of other Subject Matter Experts when necessary.
  4. Incident Management: A CISO is expected to be involved in the management of cyber incidents. A vCISO, being part-time, might struggle to handle multiple major incidents simultaneously for different clients, potentially prioritizing the one that pays better or has a longer contract remaining.

Finding the Right Balance

While vCISO and CISO-as-a-Service can be valuable solutions for organizations in transition, small businesses part of bigger groups with real CISOs (in this case I also saw a case of an internal CISO-as-a-Service, and this appears to be a great idea) and scaleup companies, it’s essential to consider potential limitations and conflicts of interest. Ideally, organizations should work towards cultivating internal talent to eventually assume the CISO role.
In cases where a trusted internal candidate is not yet ready or a CISO has recently resigned, vCISO and CISO-as-a-Service can be effective interim solutions to put paper over the cracks. However, it’s essential to ensure that the chosen provider is competent, neutral, dedicated to the organization’s best interests, and ideally has knowledge of the industry. Moreover, organizations should make sure that someone internally is identified (e.g., COO or CIO) to be accountable.

Conclusion

I may be biased since I was an advisor for a long period of my career, but these services are not that different from the “old approach,” which is still an alternative: using strategic consultancies and in-house IT and/or system integrators to complete projects. What matters is recognizing the importance of security, regardless of whether the person helping them is called a CISO-on-demand or a security advisor.

vCISO and CISO-as-a-Service can provide much-needed cybersecurity expertise, especially for small businesses and scaleup companies.

When considering the use of vCISO and CISO-as-a-Service, it is essential for organizations to carefully assess the benefits and limitations of these options. By taking into account factors such as access to expertise, competencies (and not just title and certifications), flexibility, accountability, integration, authority, long-term strategy, conflict of interest and involvement in case of incidents, businesses can make informed decisions about whether these services are the right fit for their cybersecurity strategy.

Ultimately, fostering internal talent and working towards a full-time CISO role may be the best long-term solution. Small businesses and organizations in transition can benefit from the expertise and flexibility offered by vCISO and CISO-as-a-Service but must have a holistic approach in selecting a provider who can effectively address their unique cybersecurity challenges and should continuously reevaluate their cybersecurity needs and ensure that their chosen option remains effective .

The Need for a Passwordless Future

AI, Password Cracking, and the Shift to Modern MFA

The Need for a Passwordless Future: AI, Password Cracking, and the Shift to Modern MFA
Photo by Miguel Á. Padriñán from Pexels

Introduction

As artificial intelligence (AI) continues to evolve, it’s becoming increasingly easier for it to crack passwords. This alarming statistic highlights the need for a passwordless future, where modern Multi-Factor Authentication (MFA) methods like FIDO 2 replace traditional, less secure methods.

The Power of AI in Password Cracking:

According to HomeSecurityHeroes, even a seemingly strong password can fall prey to AI-powered attacks in a matter of seconds. In fact, 51% of common passwords can be cracked in less than a minute.

Hive systems confirms this and add that even a brute-force attack using a consumer-budget desktop computer with a top-tier graphics card, or leveraging cloud compute resources, can yield worrisome results.

With the rapid evolution in AI, it’s becoming more important than ever to start evaluating a passwordless future to ensure the security of our digital assets.

Why We Should Move to Passwordless?

A passwordless future offers numerous benefits, as outlined in this Help Net Security article. Moving to passwordless solutions can:

  1. Improve security by eliminating the risk of weak or reused passwords.
  2. Enhance user experience, as there’s no need to remember complex passwords.
  3. Reduce the cost and time associated with password management.
  4. Facilitate a more straightforward and secure remote work environment.

Oh nice, but why can’t I just use a password manager and with long complex and unique passwords?

While password managers offer protection against password cracking, they are not a foolproof solution. We will cover the advantages and disadvantages of password managers in a future article, but it’s important to remember that they are not a substitute for moving towards a passwordless future.

Ok, So why can’t I just use MFA?

That’s a great idea, and I already wrote about the flaws of traditional MFA methods and merits of modern secure ones here and here so I won’t repeat myself but I’ll continue to suggest adopting modern MFA, eventually as an in between step towards a passwordless future.

Conclusion

As the ease of password cracking increases, the need for a passwordless future becomes more pressing. By moving away from traditional password-based authentication, organizations can significantly enhance their cybersecurity posture and protect their valuable digital assets.

Ok, so I just have to go for passwordless and that will solve all the problems?

Well, no (sorry, I tricked you – that wasn’t the conclusion of the article).

It’s essential to be cautious and understand the limits of technologies when implementing passwordless and MFA solutions. For instance, simply using a prompt-based MFA can leave users vulnerable to MFA prompt flooding attacks or other social engineering attacks.

Imagine removing the password and having users susceptible to MFA flooding attacks, where the attacker doesn’t even need to steal the credential first.

Microsoft is aware of this issue, which is why they offer passwordless authentication and are enabling number matching MFA for all Microsoft Authenticator users (here I describe the difference between this method and the prompt-based approach).

The Need for a Passwordless Future – Real conclusion/recommendation

First, adopt a modern MFA solution, considering its potential limits. Then, start moving away from traditional password-based authentication. This way, organizations can significantly enhance their cybersecurity posture and protect their valuable digital assets.

My Top Popular LinkedIn Posts for April 2023 🚀

April has been an eventful month in the world of cybersecurity, especially with the ChatGPT block saga taking center stage.

Let’s dive into the top popular LinkedIn posts that sparked discussions and caught some attention:

  1. Espionage Campaign Linked to Russian Intelligence: Prioritizing human security in the face of cyber threats 🕵️
  2. Darktrace NDR apparently was Hacked: A shocking revelation 😲 and its follow-up Darktrace NDR Hacked Update: A surprising turn of events 🚨
  3. Importance of Security Exercises: my interview discussing preparation of organizations for cyber incidents through regular exercises 🛡️
  4. ICO Fines TikTok 127£ Milion for Misusing Children’s Data💷

The Chat GPT saga (to put the saga in context start with my analysis on Unraveling the ChatGPT Block in Italy, shedding light on the geopolitical implications of AI and Privacy regulation 🌐 also on this site ):

  1. ChatGPT Confidentiality Issues: The risks of AI leaking sensitive information 🤯
  2. Italian DPA Blocks ChatGPT: Regulating AI to protect user privacy 🚫
  3. OpenAI Collaborates with Italian DPA: A partnership to ensure AI compliance 👥
  4. German DPA Jumps in: Safeguarding user data across borders 🇩🇪
  5. EDPB Taskforce on ChatGPT: Addressing data protection concerns on a European level 🌐
  6. ChatGPT Unblock and Resuming Services: A compliant AI returns to the market 🟢 and ChatGPT’s Italian Comeback 🇮🇹

With the exception of the aforementioned article linked to the ChatGPT Saga I’m not considering contents of this blog, even if you find those on LinkedIn these are contents of this blog.

Be sure to check back next month for another roundup of the most popular LinkedIn posts! 

« Older posts Newer posts »

© 2026 CyberSec.Cafe