Biblio

This Innovative Practice Work in Progress paper makes the case for using concept inventories in cybersecurity education and presents an example of the development of a concept inventory in the field of secure programming. The secure programming concept inventory is being developed by a team of researchers from four universities. We used a Delphi study to define the content area to be covered by the concept inventory. Participants in the Delphi study included ten experts from academia, government, and industry. Based on the results, we constructed a concept map of secure programming concepts. We then compared this concept map to the Joint Task Force on Cybersecurity Education Curriculum 2017 guidelines to ensure complete coverage of secure programming concepts. Our mapping indicates a substantial match between the concept map and those guidelines.

Malware has become sophisticated and organizations don't have a Plan B when standard lines of defense fail. These failures have devastating consequences for organizations, such as sensitive information being exfiltrated. A promising avenue for improving the effectiveness of behavioral-based malware detectors is to combine fast (usually not highly accurate) traditional machine learning (ML) detectors with high-accuracy, but time-consuming, deep learning (DL) models. The main idea is to place software receiving borderline classifications by traditional ML methods in an environment where uncertainty is added, while software is analyzed by time-consuming DL models. The goal of uncertainty is to rate-limit actions of potential malware during deep analysis. In this paper, we describe Chameleon, a Linux-based framework that implements this uncertain environment. Chameleon offers two environments for its OS processes: standard - for software identified as benign by traditional ML detectors - and uncertain - for software that received borderline classifications analyzed by ML methods. The uncertain environment will bring obstacles to software execution through random perturbations applied probabilistically on selected system calls. We evaluated Chameleon with 113 applications from common benchmarks and 100 malware samples for Linux. Our results show that at threshold 10%, intrusive and non-intrusive strategies caused approximately 65% of malware to fail accomplishing their tasks, while approximately 30% of the analyzed benign software to meet with various levels of disruption (crashed or hampered). We also found that I/O-bound software was three times more affected by uncertainty than CPU-bound software.