Towards a Self-Forensics Property in the ASSL Toolset

This preliminary conceptual work discusses a notion of self-forensics as an autonomic property to augment the Autonomic System Specification Language (ASSL) framework of formal specification tools for autonomic systems. The core of the proposed methodology leverages existing designs, theoretical results, and implementing systems to enable rapid completion of and validation of the experiments and their the results initiated in this work. Specifically, we leverage the ASSL toolkit to add the self-forensics autonomic property (SFAP) to enable generation of the Java-based Object-Oriented Intensional Programming (JOOIP) language code laced with traces of Forensic Lucid to encode contextual forensic evidence and other expressions

The Need to Support of Data Flow Graph Visualization of Forensic Lucid Programs, Forensic Evidence, and their Evaluation by GIPSY

Lucid programs are data-flow programs and can be visually represented as data flow graphs (DFGs) and composed visually. Forensic Lucid, a Lucid dialect, is a language to specify and reason about cyberforensic cases. It includes the encoding of the evidence (representing the context of evaluation) and the crime scene modeling in order to validate claims against the model and perform event reconstruction, potentially within large swaths of digital evidence. To aid investigators to model the scene and evaluate it, instead of typing a Forensic Lucid program, we propose to expand the design and implementation of the Lucid DFG programming onto Forensic Lucid case modeling and specification to enhance the usability of the language and the system and its behavior. We briefly discuss the related work on visual programming an DFG modeling in an attempt to define and select one approach or a composition of approaches for Forensic Lucid based on various criteria such as previous implementation, wide use, formal backing in terms of semantics and translation. In the end, we solicit the readers' constructive, opinions, feedback, comments, and recommendations within the context of this short discussion.Comment: 11 pages, 7 figures, index; extended abstract presented at VizSec'10 at http://www.vizsec2010.org/posters ; short paper accepted at PST'1

Toward Refactoring of DMARF and GIPSY Case Studies – a Team 3 SOEN6471-S14 Project Report

The software architecture of a system is an illustration of the system which supports the understanding of the behaviour of the system. The architecture aids as the blueprint of the system, defining the work obligations which must be conceded by design and implementation teams. It is an artifact for early enquiry to make sure that a design methodology will produce a standard system. This paper depicts the software architecture and design of two frameworks DMARF and GIPSY. Primarily it inaugurates a comprehensive understanding of the frameworks and their applications. DMARF is high-volume processing of recorded audio, textual, or imagery data for pattern recognition and biometric forensic analysis, whereas GIPSY system provides a platform for a distributed multi-tier demand driven evaluation of heterogeneous programs. Secondly, the paper illustrates the use of several tools for the code analysis for both platforms and provides the outcome of the analysis. Thirdly, it establishes the architecture and design of the systems. Fourthly, it fuses the architecture for both the systems into one. The paper ends with depicting properties like code smells and refactoring to improve code quality for the frameworks