Cloudsec.ai

I'm really excited to share that the Cloud Security Alliance just published the paper that my co-author Laura Cristiana Voicu and I have been working on for the past several months! The paper looks at many of the security concerns related to protecting data when building systems that utilize LLMs. In particular, we cover patterns and best practices where the LLM integrates with other external information sources such as vector databases, SQL databases and external APIs while touching on more advanced use cases such as using LLMs to write dynamic code and autonomous agents. ❤️ This is my first time as the lead on a peer reviewed paper and it couldn't have happened without all the feedback and contributions from many others. In particular, Malte Højmark-Bertelsen, Erik Hajnal, Jason Garman, Damian Hasse, and Tim Michaud all shared a wealth of knowledge that made this possible ❤️ A big thank you to Josh Buker, Mark Yanalitis and Michael Roza from the CSA for helping guide us through the process every step of the way! Let me know if you're working on interesting LLM based projects and want to chat more about how to best address your security concerns!

Snowflake's incident highlights that it doesn’t matter if a breach is “the customer’s fault” when enough are simultaneously breached. Your company’s name gets dragged through the mud alongside the B word regardless of fault. Is it the customer’s fault that they didn’t enable MFA and were susceptible to credentials stolen elsewhere being used to access their data? Does it matter? A large portion of employees at Snowflake are now distracted from being able to deliver value and are stuck dealing with the fallout. Snowflake’s name is being mentioned next to the word “breach” in every tech journal and newspaper. It’s not exactly where the marketing and brand teams want to be messaging from. This was absolutely foreseeable. It was also preventable, even with the shared responsibility model. Snowflake is now paying the price for the choice to risk their own reputation by tying it to customers’ proven inability to secure individual accounts. It’s almost like the lessons from the 23 and me breach just vanished into the ether. I’m sure there was some mention of “friction” when the authentication requirements were set but there’s more to it than a binary discussion of forcing MFA or not. How can you prevent something similar from occurring to your business? 💰  Stop charging extra money for SAML and SSO - Customer account security is too critical to your own brand’s well being. Why are you paywalling it? ✅  Make MFA a requirement for accounts with broad access to data or have admin rights - requiring MFA checks only for sessions from new IP addresses would stop most credential stuffing attacks with minimal user friction. 🔑  Ensure that MFA is easy to set up and use - Passkeys aren’t phishable and are impossibly easy for users. Outside of major providers however, most sites are yet to implement them. The sooner we move away from making people pull out their phones, unlock them, open their authenticator app, find the right account and copy a number manually to their computer, the better. 👀  Check passwords as they are created against databases of known compromised credentials - A lot of the passwords used in breaches are already known to be compromised or were commonly used. This is easily preventable with checks at password creation time to a site like haveibeenpwned. 🍪  Device bound session credentials - session cookie theft from malware is a growing threat that can be mitigated by ensuring that session cookies only work in the browser they were generated from. ✈️  Bind sessions to an IP and force re-authentication when the address changes - It doesn’t take a security engineer to point out that a user always in Tacoma showing up 12 minutes later in Azerbaijan might be indicative of an account issue. Service providers holding customer data should be taking steps to minimize the risk of a similarly unenviable situation, resorting to blaming their own customers who are already suffering from an account breach.

Maybe it's time for companies deriving trillions of dollars in value from open source software to think about pitching in a bit more? Yes, we can point to contributions that the big tech companies make but most of that is done developing features directly benefitting themselves commercially. In aggregate, the value provided by the OSS ecosystem is a one way street. Most companies use vast amounts of open source software without giving anything material back, despite the dependence of their business model on free software's existence. Businesses making a global, concerted effort to put even fraction of a percent of the value they gain back into efforts like OpenSSF would be a great stride towards developing a more proactive stance for security of core infrastructure that every company relies on.

No, you don’t need to allowlist all your apps or to have a data loss prevention system to be compliant. Do you find yourself doing work because your compliance app told you to? I’ve worked with multiple customers recently who have spent time and resources on work they thought they needed to do to be compliant when in reality, it barely moved the needle and saddled them with additional burdens of tuning lists and responding to false positives. I think software that helps companies get ready for infosec audits is hugely helpful for tracking the work to be done and ensuring you’re ready for an upcoming audit. I don’t think anyone using them wishes they could go back to tracking controls in a spreadsheet. In their quest to make things easier for users, they provide general control suggestions for a given compliance objective. The problem is that many companies don’t realize these are suggestions and implement them as is, rather than define appropriate controls based on risk, business objectives and context. Don’t blindly follow what your compliance app tells you to do. You know your systems and processes better than anyone. Look at the objectives for your compliance framework and ensure that the controls that map to it are ones that make sense in the context of your business. Wondering if your security compliance program is actually aligned with your needs? Send me a DM and let’s talk!

Why do security programs often focus on the wrong priorities, chasing headline-grabbing threats while proven fundamentals remain neglected? We have well-established practices for managing risk effectively but many organizations still struggle with a misalignment between perceived and actual risks, often without realizing it. Examples below: 💎 Shiny objects have a special pull on those interested in technology, including security professionals. Media covers dramatic incidents, state-sponsored attacks using 0-days and vendors constantly present new acronyms to register in the Gartner Dictionary of Security Tools You Need (You do have a CSNAARP, don’t you?) This can lead teams to prioritize high-profile threats or new tools over more mundane but more significant risks, like unpatched vulnerabilities or weak authentication. 🧠 Cognitive biases significantly influence decision-making and unless your team actively accounts for their effects, they’ll affect how you consider risks. Availability bias causes overestimation of the likelihood of a class of attack if it happened recently and received significant attention. Confirmation bias leads teams to focus on confirming existing beliefs, discounting contradictory evidence. Optimism bias, the illusion of control and the sunk cost fallacy are a few more that cloud decision making if you don’t work to counter them. 🎱 Quantifying the value of preventative measures to businesses was a difficult challenge long before the complexity of technological systems was added. Traditional ROI calculations rely on assumptions which vary widely depending on the methodology. When they’re generated without extensive collaboration or not communicated well, executives won’t have confidence in the results. To overcome this, make your risk assessment processes transparent and collaborative. By enabling participation, you build trust across the org, setting the foundation for a shared understanding of the organization's security posture. 🗺️ Dry statistics don’t convey risk in terms that the human brain can easily absorb and decision makers need to understand the business value of your recommendations. Translate statistics to a compelling story that maps the risks to critical business goals. Don’t underestimate the value of stories to make numbers more real. Make sure they're grounded in real life though 👇🏼 👹  While it's crucial to communicate potential consequences, don’t rely on fear-based tactics or overhyped statistics. Using generic figures, like the average cost of a breach from some report is a quick way to show you don’t understand statistics and undermines credibility. Instead, provide realistic, specific-to-your-org assessments of the potential impacts to help drive informed decisions about risk tolerance and resource allocation. What do you see often causing a misalignment between security and reality? Looking for help with your security program? DM me or check out my blog linked above!