Biblio

The security of embedded systems is particularly crucial given the prevalence of embedded devices in daily life, business, and national defense. Firmware for embedded systems poses a serious threat to the safety of society, business, and the nation because of its robust concealment, difficulty in detection, and extended maintenance cycle. This technology is now an essential part of the contemporary experience, be it in the smart office, smart restaurant, smart home, or even the smart traffic system. Despite the fact that these systems are often fairly effective, the rapid expansion of embedded systems in smart cities have led to inconsistencies and misalignments between secured and unsecured systems, necessitating the development of secure, hacker-proof embedded systems. To solve this issue, we created a sizable, original, and objective dataset that is based on the latest Linux vulnerabilities for identifying the embedded system vulnerabilities and we modified a cutting-edge machine learning model for the Linux Kernel. The paper provides an updated EVDD and analysis of an extensive dataset for embedded system based vulnerability detection and also an updated state of the art deep learning model for embedded system vulnerability detection. We kept our dataset available for all researchers for future experiments and implementation.

A wide range of tools exist to assist developers in creating secure software. Many of these tools, such as static analysis engines or security checkers included in compilers, use warnings to communicate security issues to developers. The effectiveness of these tools relies on developers heeding these warnings, and there are many ways in which these warnings could be displayed. Johnson et al. [46] conducted qualitative research and found that warning presentation and integration are main issues. We built on Johnson et al.'s work and examined what developers want from security warnings, including what form they should take and how they should integrate into their workflow and work context. To this end, we conducted a Grounded Theory study with 14 professional software developers and 12 computer science students as well as a focus group with 7 academic researchers to gather qualitative insights. To back up the theory developed from the qualitative research, we ran a quantitative survey with 50 professional software developers. Our results show that there is significant heterogeneity amongst developers and that no one warning type is preferred over all others. The context in which the warnings are shown is also highly relevant, indicating that it is likely to be beneficial if IDEs and other development tools become more flexible in their warning interactions with developers. Based on our findings, we provide concrete recommendations for both future research as well as how IDEs and other security tools can improve their interaction with developers.

Cloud-based payments, virtual car keys, and digital rights management are examples of consumer electronics applications that use secure software. White-box implementations of the Advanced Encryption Standard (AES) are important building blocks of secure software systems, and the attack of Billet, Gilbert, and Ech-Chatbi (BGE) is a well-known attack on such implementations. A drawback from the adversary’s or security tester’s perspective is that manual reverse engineering of the implementation is required before the BGE attack can be applied. This paper presents a method to automate the BGE attack on a class of white-box AES implementations with a specific type of external encoding. The new method was implemented and applied successfully to a CHES 2016 capture the flag challenge.

Confidentiality, Integrity, and Availability are principal keys to build any secure software. Considering the security principles during the different software development phases would reduce software vulnerabilities. This paper measures the impact of the different software quality metrics on Confidentiality, Integrity, or Availability for any given object-oriented PHP application, which has a list of reported vulnerabilities. The National Vulnerability Database was used to provide the impact score on confidentiality, integrity, and availability for the reported vulnerabilities on the selected applications. This paper includes a study for these scores and its correlation with 25 code metrics for the given vulnerable source code. The achieved results were able to correlate 23.7% of the variability in `Integrity' to four metrics: Vocabulary Used in Code, Card and Agresti, Intelligent Content, and Efferent Coupling metrics. The Length (Halstead metric) could alone predict about 24.2 % of the observed variability in ` Availability'. The results indicate no significant correlation of `Confidentiality' with the tested code metrics.

Software has become an integral part of every industry and organization. Due to improvement in technology and lack of expertise in coding techniques, software vulnerabilities are increasing day-by-day in the software development sector. The time gap between the identification of the vulnerabilities and their automated exploit attack is decreasing. This gives rise to the need for detection and prevention of security risks and development of secure software. Earlier the security risk is identified and corrected the better it is. Developers needs a framework which can report the security flaws in their system and reduce the chances of exploitation of these flaws by some malicious user. Common Vector Scoring System (CVSS) is a De facto metrics system used to assess the exploitability of vulnerabilities. CVSS exploitability measures use subjective values based on the views of experts. It considers mainly two factors, Access Vector (AV) and Authentication (AU). CVSS does not specify on what basis the third-factor Access Complexity (AC) is measured, whether or not it considers software properties. Our objective is to come up with a framework that automates the process of identifying vulnerabilities using software structural properties. These properties could be attack entry points, vulnerability locations, presence of dangerous system calls, and reachability analysis. This framework has been tested on two open source softwares - Apache HTTP server and Mozilla Firefox.

Software security is an important aspect that needs to be considered during the entire software development life cycle (SDLC). Integrating software security at each phase of SDLC has become an urgent need. To address software security, various approaches, techniques, methods, practices, and models have been proposed and developed. However, recent research shows that many software development methodologies do not explicitly include methods for incorporating software security during the development of software as it evolves from requirements engineering to its final disposal. The primary objective of this research is to study the state-of-the-art of security in the context of SDLC by following systematic mapping study (SMS). In the second phase, we will identify, through systematic literature review (SLR) and empirical study in the industry, the software security contributions, security challenges and their practices for global software development (GSD) vendors. The ultimate aim is to develop a Software Security Assurance Model (SSAM) to assist GSD vendor organisations in measuring their readiness towards the development of secure software.

There is widening chasm between the ease of creating software and difficulty of "building security in". This paper reviews the approach, the findings and recent experiments from a seven-year effort to enable consistency across a large, diverse development organization and software portfolio via policies, guidance, automated tools and services. Experience shows that developing secure software is an elusive goal for most. It requires every team to know and apply a wide range of security knowledge in the context of what software is being built, how the software will be used, and the projected threats in the environment where the software will operate. The drive for better outcomes for secure development and increased developer productivity led to experiments to augment developer knowledge and eventually realize the goal of "building the right security in".