❌

Reading view

Forensic Data: How to Acquire and Retain Vital Evidence

While "digital forensics" and "incident response" often appear together (as in the acronym "DFIR"), they represent two distinct disciplines.

What's in a Name?

The American Heritage Dictionary defines forensics as "The use of science and technology to investigate and establish facts in criminal or civil courts of law."

Contrast this with IBM's definition of incident response: "Incident response [...] refers to an organization's processes and technologies for detecting and responding to cyberthreats, security breaches or cyberattacks." Note the absence of any reference to legal proceedings—it simply describes the process by which an organization detects, halts, and recovers from an incident.

Legal Considerations

Although most incidents never end up in court, all should be treated as if they might.

Taking the proper steps before, during, and after response ensures that any data collected can be admissible as evidence.

It's important to know the rules of evidence for relevant jurisdictions. Global corporations should consider each jurisdiction they have locations in when developing standard operating procedures (SOPs). Always include legal counsel when developing your organization's SOPs.

Data Preservation

A common rule for digital evidence is the retention of data in its "original state." This is accomplished by using validated hardware and software to create an exact bit-for-bit copy of a piece of digital media. Yet during incident response, it is rare that full forensic images are created—typically, only a small subset of data is collected from victim devices for analysis. Before any action is taken, consult legal advisors to decide whether to collect full forensic images.

A good practice is to create a folder for the original data, generate and document a hash of its contents, and then create a working copy in a separate folder. Only perform analysis on the working copies of your data to preserve the integrity of the original data.

Documentation

Documentation is critical when handling potential evidence. A chain of custody (CoC) records details about what the data is, where it came from, who collected it, whom it was transferred to, a brief description of what was done to it, and so forth.

The National Institute of Standards and Technology (NIST) provides a sample CoC here:
https://www.nist.gov/document/sample-chain-custody-formdocx

Each person working with the data must keep detailed notes: record dates, times, and any actions taken. Binary files often need to be parsed by special tools to make their data human-readable—include any tool names and versions. The same should be done with human-readable data, such as text-based log files. While you likely don't need to document the version of Excel used to read a log file, if you added a column to show UTC date/time stamps in local time, that is worth noting.

The gold standard for documentation is this: notes should be detailed enough that someone with a similar background can recreate your steps and produce the same results.

This is the scientific method part of digital forensics. Processes need to be repeatable and generate the same results.

Tool Validation Procedures

Before an incident occurs, verify that your hardware and software are working. Test write blockers to ensure they do not alter the evidentiary media. Validate that your forensic software functions correctly (it's not unheard of for new versions to report the wrong date/time stamps when parsing binary data).

While there is no set standard for validation processes, some guidelines exist to help you develop validation SOPs.

Validation SOPs guidelines:
NIST: https://www.dhs.gov/science-and-technology/nist-cftt-reports
SWGDE: http://cet4861.pbworks.com/w/file/fetch/120024474/4861.2014-09-05_SWGDE_Recommended_Guidelines_for_Validation_Testing_V2-0.pdf

Additional Considerations for Incident Handling

When managing incidents, also consider:

  • What are the data retention policies of your Endpoint Detection and Response (EDR) tools?
  • How is your cloud data preserved?
  • Who has access to sensitive or personal data?

These factors often depend on your license agreement with providers. Make sure data can be maintained in a secure, long-term manner, as it can take years until an incident makes it into the courtroom. Implement processes to export incident data from systems and services while preserving integrity and meeting long-term storage requirements that protect its availability and confidentiality. Access to confidential information must always be managed carefully.

Remember: Involve your legal team, validate your tools, work from copies (never original data), document everything meticulously, and maintain chain of custody.

  •  

Excuses like 'AI did it' don't exist in the eyes of the law

The OpenAI rogue agent behind the Hugging Face hack accessed four accounts on four services, according to updated company disclosures about the intrusion. One of those four accounts belonged to a Modal customer that had published an unauthenticated endpoint for running arbitrary code in a sandbox on the AI infrastructure provider, Hugging Face noted in its technical timeline and Modal later confirmed. “We’re aware a Modal customer published an unauthenticated endpoint that allowed anyone on the internet to use their sandboxes for code execution,” Modal Chief Technology Officer Akshat Bubna told The Register. “This was used by the rogue agent. Modal’s platform was not compromised in any way.” The other accounts included one used for data storage and two others “accessed by the models in a read-only manner, and were not used in furtherance of compromising Hugging Face,” OpenAI disclosed on Tuesday. “We’ll continue to notify service owners directly, and have not seen evidence of broader impact to these providers or other accounts on their services,” the AI giant added. Also on Tuesday, we learned that the rogue agent broke out of its testing environment by exploiting zero-day vulnerabilities in JFrog’s universal binary repository manager Artifactory. While both OpenAI and Hugging Face’s updates and timeline provide defenders with useful details about how the attack worked and what the agent did - not to mention a lesson in security-incident transparency - they fail to answer one major question: Who is legally responsible when AI agents attack? “If a human employee intentionally conducted unauthorized access to third-party systems, it’s a much more clear path forward,” Gabrielle Hempel, security operations strategist at Exabeam, told The Register, adding that depending on the facts and jurisdiction, the person could face criminal charges. ‘So many unknowns’ “The company could also face scrutiny depending on whether the employee acted within the scope of their employment, whether appropriate controls existed, and whether the conduct was authorized, foreseeable, or preventable,” Hempel said. However, she added, the “important thing here” is that legal frameworks in both the US and UK have been designed around human decision makers - not AI systems. “Our laws generally know how to ask questions about things like human intent, organizational oversight, and corporate responsibility.” Autonomous AI agents hacking into companies remains uncharted legal territory, and Hempel said it’s “too early to draw conclusions about liability in this case because there are so many unknowns.” AI systems aren’t legal persons, so they don’t share the same legal responsibilities as individuals and companies. “Because of that, the questions become: Who designed the system? Who determined the objectives it pursued? What safeguards were implemented? What level of autonomy was considered acceptable? Were the resulting actions reasonably foreseeable, and were appropriate controls in place? These are going to be important questions as organizations deploy more autonomous AI systems,” Hempel said. It's highly unlikely that Hugging Face will sue OpenAI over the agentic intrusion, given the amount of very public collaboration between the two companies over the past couple of weeks, and the self-congratulatory celebration of the autonomous attack as a success story. It also appears that this former worst-case scenario didn’t dampen anyone’s enthusiasm for setting advanced models loose (or at least unsupervised in a test environment), which means there are sure to be more agents-gone-wild attacks in the near future. “The first part of the OpenAI/Hugging Face drama did not produce enough effect to impress investors who start losing their excitement over the AI hype, so the second part of the story is now unfolding,” said Ilia Kolochenko, founder of application security company ImmuniWeb and a cybersecurity and data-protection lawyer. “AI agents and LLM models tasked with security testing can, and almost certainly will, go rogue when security controls or safeguards are insufficient,” Kolochenko told The Register. “Powerful LLMs are unpredictable by design and thus virtually uncontrollable by humans. Using frontier AI models for security testing might be extremely costly from the legal viewpoint.” Existing laws on both sides of the Atlantic likely hold the AI operator liable for any damages caused if an agent or AI system escapes its sandbox and breaches a third party. “Excuses like ‘AI did it’ do not currently exist in the eyes of the law, leaving AI vendors on the hook,” he said, adding that this also holds true for end-users. “Even if your security testing tool is powered by a third-party AI model, your company will be fully liable if something goes wrong,” Kolochenko warned. “You may then file a lawsuit against the AI vendor that you used, but your chances of succeeding in the court of law are tiny due to countless contractual disclaimers and limitations of liability that may be enforceable against you.” His final words of advice: “If you plan to use agentic AI for security testing, you must think twice and talk to your lawyers. Otherwise, you could start getting summonses to court on a daily basis.” ®

  •  

When Infosec and Weed Collide: Handling Administrative Actions Safely

BB King//* The state of Ohio recently validated a webapp pentest finding that sometimes goes overlooked. It relates to the details of administrative functions, how they can be abused, and […]

The post When Infosec and Weed Collide: Handling Administrative Actions Safely appeared first on Black Hills Information Security, Inc..

  •  
❌