August 14, 2024

MIT releases comprehensive database of AI risks

While numerous organizations and researchers have recognized the importance of addressing AI risks, efforts to document and classify these risks have been largely uncoordinated, leading to a fragmented landscape of conflicting classification systems. ... The AI Risk Repository is designed to be a practical resource for organizations in different sectors. For organizations developing or deploying AI systems, the repository serves as a valuable checklist for risk assessment and mitigation. “Organizations using AI may benefit from employing the AI Risk Database and taxonomies as a helpful foundation for comprehensively assessing their risk exposure and management,” the researchers write. “The taxonomies may also prove helpful for identifying specific behaviors which need to be performed to mitigate specific risks.” ... The research team acknowledges that while the repository offers a comprehensive foundation, organizations will need to tailor their risk assessment and mitigation strategies to their specific contexts. However, having a centralized and well-structured repository like this reduces the likelihood of overlooking critical risks.

Why Agile Alone Might Not Be So Agile: A Witty Look at Methodology Madness

Agile’s problems often start with a fundamental misunderstanding of what it truly means to be agile. When the Agile Manifesto was penned back in 2001, its authors intended it to be a flexible, adaptable approach to software development, free from the rigid structures and bureaucratic procedures of traditional methodologies. But fast forward to today, and Agile has become its own kind of bureaucratic monster in many organizations — a tyrant disguised as a liberator. Why does this happen? Let’s dissect the two main problems: the roles defined within Agile and the one-size-fits-all mentality that organizations apply to Agile methodology. One of the biggest hurdles to successful Agile adoption is the disconnect between the executive suite and the teams on the ground. Executives often see Agile as a magic bullet for faster delivery and higher productivity, without fully understanding the nuances of the methodology. This disconnect can lead to unrealistic demands and pressure on teams to deliver more with each Sprint, which in turn leads to burnout and decreased quality. Moreover, the Agile Manifesto’s disdain for comprehensive documentation can be problematic in complex projects.?

Feature Flags Wouldn’t Have Prevented the CrowdStrike Outage

Feature flagging is a valuable technique for decoupling the release of new features from code deployment, and advanced feature flagging tools usually support percentage-based rollouts. For example, you can enable a feature on X% of targets to ensure it works before reaching 100%. While it’s true that feature flags can help to prevent outages, given the scale and complexity of the CrowdStrike incident, they would not have been sufficient for three reasons. First, a comprehensive staged rollout requires more than just “gradually enable this flag over the next few days”:There has to be an integration with the monitoring stack to perform health checks and stop the rollout if there are problems. There has to be a way to integrate with the CD pipeline to reuse the list of targets to roll out to and a list of health checks to track. Available feature flagging solutions require much work and expertise to support staged rollout at any reasonable scale. Second, CrowdStrike’s config had a complex structure requiring a “configuration system” and a “content interpreter.” Such configs would benefit from first-class schema support and end-to-end type safety.?

Putting Threat Modeling Into Practice: A Guide for Business Leaders

One of the primary benefits of threat modeling is its ability to reduce the number of defects that make it to production. By identifying potential threats and vulnerabilities during the design phase, companies can implement security measures that prevent these issues from ever reaching the production environment. This proactive approach not only improves the quality of products but also reduces the costs associated with post-production fixes and patches. ... Threat modeling helps us create reusable artifacts and reference patterns as code, which serve as blueprints for future projects. These patterns encapsulate best practices and lessons learned, ensuring that security considerations are consistently applied across all projects. By embedding these reference patterns into development processes, organizations reduce the need to reinvent the wheel for each new product, saving time and resources. ... The existence of well-defined reference patterns reduces the likelihood of errors during development. Developers can rely on these patterns as a guide, ensuring that they follow proven security practices without having to start from scratch.?

The magic of RAG is in the retrieval

The role of the LLM in a RAG system is to simply summarize the data from the retrieval model’s search results, with prompt engineering and fine-tuning to ensure the tone and style are appropriate for the specific workflow. All the leading LLMs on the market support these capabilities, and the differences between them are marginal when it comes to RAG. Choose an LLM quickly and focus on data and retrieval. RAG failures primarily stem from insufficient attention to data access, quality, and retrieval processes. For instance, merely inputting large volumes of data into an LLM with an expansive context window is inadequate if the data is excessively noisy or irrelevant to the specific task. Poor outcomes can result from various factors: a lack of pertinent information in the source corpus, excessive noise, ineffective data processing, or the retrieval system’s inability to filter out irrelevant information. These issues lead to low-quality data being fed to the LLM for summarization, resulting in vague or junk responses. It’s important to note that this isn’t a failure of the RAG concept itself. Rather, it’s a failure in constructing an appropriate “R” — the retrieval model.

What enterprises say the CrowdStrike outage really teaches

CrowdStrike made two errors, enterprises say. First, CrowdStrike didn’t account for the sensitivity of its Falcon client software for endpoints to the tabular data that described how to look for security issues. As a result, an update to that data crashed the client by introducing a condition that had existed before but hadn’t been properly tested. Second, rather than doing a limited release of the new data file that would almost certainly have caught the problem and limited its impact, CrowdStrike pushed it out to its entire user base. ... The 37 who didn’t hold Microsoft accountable pointed out that security software necessarily has a unique ability to interact with the Windows kernel software, and this means it can create a major problem if there’s an error. But while enterprises aren’t convinced that Microsoft contributed to the problem, over three-quarters think Microsoft could contribute to reducing the risk of a recurrence. Nearly as many said that they believed Windows was more prone to the kind of problem CrowdStrike’s bug created, and that view was held by 80 of the 89 development managers, many of whom said that Apple’s MacOS or Linux didn’t pose the same risk and that neither was impacted by the problem.

Read more here ...