Security Development Lifecycle Research Articles

ОСОБЕННОСТИ ПРОГРАММНОЙ АРХИТЕКТУРЫ ЯЗЫКОВОЙ ПЛАТФОРМЫ PLIF ДЛЯ АНАЛИЗА БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ПОТОКОВ В АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ

A lot of research in the field of formal security models have been conducted so far. Information flow control in automated systems software represents one of important directions. Appropriate mechanisms are being investigated in attempt to embed them into modern programming platforms designated for system and application software creation. Today all such studies are of academic type, they have theoretical meaning and usually end up at stage of prototype. According to those authors the main problem in adopting such mechanisms for industrial use and including respective steps into security development lifecycle is complexity of manual code markup with security labels and security warnings checking. We present a new platform for detecting illegal information flows in database program units and outline the respective testing procedure which explicitly separates the responsibilities of developers from that of security analysts.

CHANGING SECURITY WITH EVERY SPIRAL

The Microsoft SDL integrates security and privacy considerations at every stage of development, assisting programmers in creating highly secure software while also addressing security compliance needs and lowering development costs (“[1]”). The software model: Spiral is crucial to this lifecycle's perspective. Microsoft has proposed the Microsoft Security Development Lifecycle (Microsoft SDL), a software development method based on the spiral model, to assist developers in producing software or applications while lowering security concerns, addressing security flaws, and even lowering development and maintenance costs. Training, requirements gathering, design, implementation, testing, deployment, and reviews are the seven phases that make up the process which is further explained in twelve different methodologies of the lifecycle model created by them. KEYWORDS: Microsoft, Software Engineering, Spiral Mode.

Inside the Windows Security Push: A Twenty-Year Retrospective

This article is a follow-up to an article on the Windows security push in the first issue of <italic xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">IEEE Security and Privacy</i> (January 2003). It provides additional detail on the security push and its results, and describes the creation and evolution of the Security Development Lifecycle (SDL) that integrated software security into Microsoft's development process. The article concludes with a summary of lessons learned about effective ways of creating secure software at scale.

Blockchain-based model for tracking compliance with security requirements

The increasing threat landscape in Industrial Control Systems (ICS) brings different risk profiles with comprehensive impacts on society and safety. The complexity of cybersecurity risk assessment increases with a variety of third-party software components that comprise a modern ICS supply chain. A central issue in software supply chain security is the evaluation whether the secure development lifecycle process (SDL) is being methodologically and continuously practiced by all vendors. In this paper, we investigate the possibility of using a decentralized, tamper-proof system that will provide trustworthy visibility of the SDL metrics over a certain period, to any authorized auditing party. Results of the research provide a model for creating a blockchain-based approach that allows inclusion of auditors through a consortium decision while responding to SDL use cases defined by this paper. The resulting blockchain architecture successfully responded to requirements mandated by the security management practice as defined by IEC 62443-4-1 standard.

Исследование свойств алгоритма слайсинга предиката пути

Security development lifecycle (SDL) is applied to improve software reliability and security. It extends program lifecycle with additional testing of security properties. Among other things, fuzz testing is widely used, which allows one to detect crashes and hangs of the analyzed code. The hybrid approach that combines fuzzing and dynamic symbolic execution showed even greater efficiency than classical fuzzing. Moreover, symbolic execution empowers one to add additional runtime checks called security predicates that detect memory errors and undefined behavior. This article explores the properties of the path predicate slicing algorithm that eliminates redundant constraints from a path predicate without accuracy loss. The article proves that the algorithm is finite and does not lose solutions. Moreover, the algorithm asymptotic complexity is estimated.

Error detection in binary code with dynamic symbolic execution

Modern software is rapidly developing, revealing new program errors. More and more companies follow security development lifecycle (SDL). Fuzzing and symbolic execution are among the most popular options for supporting SDL. They allow to automatically test programs and find errors. Hybrid fuzzing is one of the most effective ways to test programs, which combines these two techniques. Checking security predicates during symbolic execution is an advanced technique, which focuses on solving extra constraints for input data to find an error and generate an input file to reproduce it. In this paper we propose a method for automatically detecting errors with the help of dynamic symbolic execution, combining hybrid fuzzing and checking security predicates. Firstly, we run hybrid fuzzing, which is required to increase number of corpora seeds. Then we minimize corpora. Thus, it would give the same coverage as the original corpora. After that we check security predicates on minimized corpora. Thus, security predicates allow to find errors like division by zero, out of bounds access, integer overflow, and more. Security predicates results are later verified with sanitizers to filter false positive results. As a result of applying the proposed method to different open source programs, we found 11 new different errors in 5 projects.

A hybrid threat model for system-centric and attack-centric for effective security design in SDLC

Threat modeling is an essential activity in the security development lifecycle. To provide security at the design phase of software development, Microsoft introduced threat modeling stride to identify the vulnerabilities and attacks of application. An efficient solution is necessary to deal with these issues in the software development life cycle. In this context, the paper focused on the analysis of threats and attack tree techniques that are traditionally available and frequently used. Automated Threat modeling enables to simulate attacks and visualized the existing vulnerabilities and misconfiguration. A hybrid model is proposed based on system-centric and attacker-centric to identify the threats in the software application during the software design phase. This model is built by STRIDE by defining security architecture and then analyzed the risks regarding its security characteristics and applied to its real application system. Our model is applied in a case study of the health center management system and shows a better result is identifying the threats and severity in the design phase. And also attack tree defines the stages of threats to understand the severity.

Об особенностях фаззинг-тестирования сетевых интерфейсов в условиях отсутствия исходных текстов

The digital transformation of society is leading to the creation of a large number of distributed automated information systems in various areas of modern life. The need to meet security and reliability requirements prompts the creation of tools for their automated testing. Fuzzing within the security development lifecycle (SDL) is a strictly required tool for solving this problem. Tools for fuzzing binary-only applications are in demand too. These kind of fuzzing tools provide the search for critical defects in already functioning systems. It is especially acute when researching the security of proprietary systems operating using closed protocols. In the course of the research, it was found out that for fuzzing network applications in the absence of source codes, the use of universal fuzzers is complicated by many factors. These circumstances are pushing for the creation of an easy-to-use tool for network applications fuzzing. The paper discusses the features of fuzzing of this kind of programs and suggests possible solutions to the identified tasks.

Security in agile software development: A practitioner survey

Abstract Context: Software security engineering provides the means to define, implement and verify security in software products. Software security engineering is performed by following a software security development life cycle model or a security capability maturity model. However, agile software development methods and processes, dominant in the software industry, are viewed to be in conflict with these security practices and the security requirements. Objective: Empirically verify the use and impact of software security engineering activities in the context of agile software development, as practiced by software developer professionals. Method: A survey ( N = 61 ) was performed among software practitioners in Finland regarding their use of 40 common security engineering practices and their perceived security impact, in conjunction with the use of 16 agile software development items and activities. Results: The use of agile items and activities had a measurable effect on the selection of security engineering practices. Perceived impact of the security practices was lower than the rate of use would imply: This was taken to indicate a selection bias, caused by e.g. developers’ awareness of only certain security engineering practices, or by difficulties in applying the security engineering practices into an iterative software development workflow. Security practices deemed to have most impact were proactive and took place in the early phases of software development. Conclusion: Systematic use of agile practices conformed, and was observed to take place in conjunction with the use of security practices. Security activities were most common in the requirement and implementation phases. In general, the activities taking place early in the life cycle were also considered most impactful. A discrepancy between the level of use and the perceived security impact of many security activities was observed. This prompts research and methodological development for better integration of security engineering activities into software development processes, methods, and tools.

Adversarial Machine Learning - Industry Perspectives

Based on interviews with 28 organizations, we found that industry practitioners are not equipped with tactical and strategic tools to protect, detect and respond to attacks on their Machine Learning (ML) systems. We leverage the insights from the interviews and we enumerate the gaps in perspective in securing machine learning systems when viewed in the context of traditional software security development. We write this paper from the perspective of two personas: developers/ML engineers and security incident responders who are tasked with securing ML systems as they are designed, developed and deployed ML systems. The goal of this paper is to engage researchers to revise and amend the Security Development Lifecycle for industrial-grade software in the adversarial ML era.

SECURING SOFTWARE DEVELOPMENT STAGES USING ASPECT-ORIENTATION CONCEPTS

In the past 10 years, the research community has produced a significant number of design notations to represent security properties and concepts in a design artifact. The need to improve the security of software has become a key issue for developers.The security function needs to be incorporated into the software development process at the requirement, analysis, design, and implementation stages as doing so may help to smooth integration and to protect systems from attack. Security affects all aspects ofa software program, which makes the incorporation of security features a crosscutting concern. Therefore, this paper looks at the feasibility and potential advantages of employing an aspect orientation approach in the software development lifecycle to ensure efficient integration of security.These notations are aimed at documenting and analyzing security in a software design model. It also proposes a model called the Aspect-Oriented Software Security Development Life Cycle (AOSSDLC), which covers arrange of security activities and deliverables for each development stage. It is concluded that aspect orientation is one of the best options available for installing security features not least because of the benefit that no changes need to be made to the existing software structure.

The Security Development Lifecycle in the Context of Accreditation Policies and Standards

The proposed security development lifecycle (SecDLC) model delivers a perpetual cycle of information security management and refinement. Using real-world examples, the authors show how SecDLC ensures the goals of preserving, monitoring, and improving security practices, policies, and standards in private and public sectors. The authors describe the four phases of SecDLC, comparing and contrasting them to existing security development models.

정보보호 사전점검 활성화를 위한 점검항목 개선 연구

ABSTRACT IT environments such as IoT, SNS, BigData, Cloud computing are changing rapidly. These technologies add new technologies to some of existing technologies and increase the complexity of Information System. Accordingly, they require enhancing the security function for new IT services. Information Security Pre -inspection aims to assure stability and reliability for user a nd supplier of new IT services by proposing development stage whic h considers security from design phase. Existing ‘Information Security Pre-inspection’ (22 domains, 74 control items, 129 det ail items) consist of 6 stage (Requirements Definition, Design, Training, Implementation, Test, Sustain). Pilot tests were exec uted for one of IT development companies to verify its effectiveness. Consequently, for some inspection items, some improvement requirements and reconstitution needs appeared. This paper conducts a study on activation of ‘Information Security P re-inspection’ which aims to construct prevention system for ne w information system. As a result, an improved ‘Information Security Pre-inspection’ is suggested. This has 16 domains, 54 inspection items, 76 detail items which include some improvemen t requirements and reconstitution needs. Keywords: Information Security Pre-Inspection, Security Development Life cycle

Building in security

Many of the security vulnerabilities that plague us can be traced to software flaws. This is nothing new: from buffer overflows to SQL injection and cross-site scripting flaws, errors or lack of care by programmers continue to offer attackers a way into our systems. Most of these problems are well understood, so why do they persist? We spoke to Justin Clarke, director and co-founder of Gotham Digital Science, a firm specialising in secure development lifecycle, and the London chapter leader for OWASP.1

Web Engineering Security (WES) Methodology

The World Wide Web has had a significant impact on basic operational economical components in global information rich civilizations. This impact is forcing organizations to provide justification for security from a business case perspective and to focus on security from a web application development environment perspective. This increased focus on security was the basis of a business case discussion and led to the acquisition of empirical evidence gathered from a high level Web survey and more detailed industry surveys to analyse security in the Web application development environment. Along with this information, a collection of evidence from relevant literature was also gathered. Individual aspects of the data gathered in the previously mentioned activities contributed to the proposal of the Essential Elements (EE) and the Security Criteria for Web Application Development (SCWAD). The Essential Elements present the idea that there are essential, basic organizational elements that need to be identified, defined and addressed before examining security aspects of a Web Engineering Development process. The Security Criteria for Web Application Development identifies criteria that need to be addressed by a secure Web Engineering process. Both the EE and SCWAD are presented in detail along with relevant justification of these two elements to Web Engineering. SCWAD is utilized as a framework to evaluate the security of a representative selection of recognized software engineering processes used in Web Engineering application development. The software engineering processes appraised by SCWAD include: the Waterfall Model, the Unified Software Development Process (USD), Dynamic Systems Development Method (DSDM) and eXtreme Programming (XP). SCWAD is also used to assess existing security methodologies which are comprised of the Orion Strategy; Survivable / Viable IS approaches; Comprehensive Lightweight Application Security Process (CLASP) and Microsoft’s Trust Worthy Computing Security Development Lifecycle. The synthesis of information provided by both the EE and SCWAD were used to develop the Web Engineering Security (WES) methodology. WES is a proactive, flexible, process neutral security methodology with customizable components that is based on empirical evidence and used to explicitly integrate security throughout an organization’s chosen application development process. In order to evaluate the practical application of the EE, SCWAD and the WES methodology, two case studies were conducted during the course of this research. The first case study describes the application of both the EE and SCWAD to the Hunterian Museum and Art Gallery’s Online Photo Library (HOPL) Internet application project. The second case study presents the commercial implementation of the WES methodology within a Global Fortune 500 financial service sector organization. The assessment of the WES methodology within the organization consisted of an initial survey establishing current security practices, a follow-up survey after changes were implemented and an overall analysis of the security conditions assigned to projects throughout the life of the case study.

Software Security

Summary form only given. Software security has come a long way in the last few years, but we've really only just begun. I will present a detailed approach to getting past theory and putting software security into practice. The three pillars of software security are applied risk management, software security best practices (which I call touchpoints), and knowledge. By describing a manageably small set of touchpoints based around the software artifacts that you already produce, I avoid religious warfare over process and get on with the business of software security. That means you can adopt the touchpoints without radically changing the way you work. The touchpoints I will describe include: code review using static analysis tools; architectural risk analysis; penetration testing; security testing; abuse case development; and security requirements. Like the yin and the yang, software security requires a careful balance-attack and defense, exploiting and designing, breaking and building-bound into a coherent package. Create your own Security Development Lifecycle by enhancing your existing software development lifecycle with the touchpoints

Technology Transfer: A Software Security Marketplace Case Study

This paper presents the software security (application security) solutions. It is an idea of engineering software so that it continues to function correctly under malicious attack. Although as a discipline software security is relatively young, much progress has been made on ways to integrate security best practices into the software development life cycle. Microsoft, for example, has helped spearhead soft ware security through its Trustworthy Computing Initiative and the resulting Security Development Lifecycle (SDL). Cigital has also been instrumental in bringing software security to the wider market through its professional services.

On Security Development Lifecycle: Conceptual Description of Vulnerabilities, Risks, and Threats

Security Development Lifecycle (SDL) is a software assurance methodology that aims at assisting software developers in improving the security of software production. Typically SDL is described in terms of phases that include requirements and design phases. The Requirements phase embraces consideration of security and privacy at a foundational level. This consideration comprises several activities in security requirements, security risk assessment, and threat modeling. The problem is that basic notions at this level are categorized and conceptualized as arbitrary collections of assets, operations, techniques, etc. with no systematic connection between them. This paper is part of an effort that aims at building a uniform foundation for notions in SDL. It focuses on requirements phase analysis, where we analyze conceptual aspects that involve the notions of threats, risks, and vulnerabilities. We work on two aspects: 1. The notions of threats, risks, and vulnerabilities are conceptualized utilizing a new approach based on the notion of flow. 2. The flow-based methodology is presented as an alternative description to using data flow diagrams as a first step in modeling threats. In both cases the analysis is performed utilizing sample cases.

Software Security in Practice

This department is about building software with security in mind. Since it began in 2004, it has focused on the kinds of activities that constitute a secure development life cycle. As of to day, we're broadening that charter to include all the essential ingredients of a sustained soft ware security initiative. Instead of focusing on one turn of the crank that yields one new piece of software, we'll consider the ongoing organizational commitments necessary to facilitate se cure software development.

Security development lifecycle

The increasing adoption of “client and cloud” computing raises several important concerns about security. This article discusses security issues that are associated with “client and cloud” and their impact on organizations that host applications “in the cloud.” It describes how Microsoft minimizes the security vulnerabilities in these, possibly mission-critical, platforms and applications by following two, complementary approaches: developing the policies, practices, and technologies to make their “client and cloud” applications as secure as possible, and managing the security of the platform environment through clearly defined operational security policies.