THE SOFTWARE SECURITY KNOWLEDGE

 THE SOFTWARE SECURITY KNOWLEDGE

¹ Aliya Siddique ² Dr. Muhammad Naeem

Laureate Folks International

ERC, PAKISTAN

https://laureatefolks.blogspot.com

laureatefolks@gmail.com, WhatsApp: +923334446261

1.      INTRODUCTION

This report provides a high-level analysis of current practices, guidelines, daily existence approaches, paradigms, and techniques that help or may help secure software design. The original study, published in 2006, has been revised to highlight recent developments.

The goal of this Safe Software Lifecycle knowledge area is to present you with a general understanding of the software development procedures that go into making security systems.  To help people in the industry who want to use the secure software lifecycle and then use it in academic subjects on computer security is the purpose of this analysis. The Cyber Security Body of Knowledge's Software is an area that presents the structured and comprehensive review of the recognized types of software, development weaknesses, as well as approaches for preventing, detecting, and mitigating their use. This type of statement reflects the characteristics of complete software development for preventing and identifying all the security flaws to respond to an attack.

Methodologies for establishing privacy in devices and hardware networks are the subject of cyber security. The rapid evolution of World Wide Web computer systems that store sensitive data and perform vital functions has heightened interest to secure software (Fabian, Heisel, Santen, Gurses and Schmidt, 2010).  Software development at the moment techniques imposes during the security measures the plan level, that results in the specification of architecture that is concerned with security limitations aren't required. Consequently, the final software program may rely on ineffective mechanisms that cost a lot of money.

As a result, security measures were developed initially in the SDLC (Life Cycle of Software Development). Safety standards, according to (Firesmith and Donald, 2003) elevated standards that specify system behavior while distinguishing them from protection, architectural restrictions, allowing professionals and experts to find security standards.

Abuse case (Fox and Dermott, 1999), misuse case (Alexander, 2003), (Opdahl and Guttorm, 2005), Common Criteria (Bowles, Ware, and Eastman, 2006), attack trees (Ellison, 2005) are examples of proposals for detecting and expressing security standards. The reduction of various types of risk linked with hazards is subject to security needs. Risks, measured in prioritized security standards. EBIOS (BIOS: 2004), OCTAVE (Dorofee and Alberts, 2001), CORAS, and CRAMM are examples of risk management methods that impose levels of security depending on the risk measures. However, traditional software development processes do not incorporate these system safety approaches.

There have been some latest suggestions on secure development (Ray, Georg, and France, 2002; Pouzadi and Apvrille, 2005), which include language features and techniques such as stable security forces extension of troops research methods (Manson, Giorgini, Philip and Mouratidis, 2002), an intentional anti-model extension of KAOS research methods with safety necessity focused structure( Van Lamsweerde, 2004), and unify security structures and risk assessment ideas in systems development method ( Heymans, Mayer and Matulevičius, 2007).

A system requirement structure (Laney, Haley, and Moffett, 2008) mentions architecture to make safety needs easier to produce, but it ignores the architectural restrictions of a specific developmental context. Engineers have yet to devise a mechanism for applying those concepts with their programs or addressing security concerns while making structural, cognitive, and interface layout considerations.

Software development that is secure is a process for building hardware that incorporates security throughout the entire software development life cycle (commonly referred to as DevSecOps) (SDLC). Instead of being corrected after testing exposes severe product vulnerabilities, security built into the code from the beginning. Long before, a single line of code is produced; security is considered a part of the planning step.

Generally, designers have considered security a barrier to innovativeness, causing problems with getting a product on the market. This mode of thinking harms a firm's financial performance because fixing a problem during development is six times costlier and 15 times more expensive than fixing the identical issue while assessing.

2.      SOFTWARE SECURITY

To boost the reliability of the system Software Security is a method that secures against danger and sustains safety flaws (Chandra, 2010). The goal of software security is to understand the hacker and predict motives and perceptions. Designing application security is no longer an option; it is now a requirement for any software company. Generally, application development has been conceived of as the process of creating software that functions normally. Whenever security is combined with application development, the designer and developer's focus shifts to the attacker's viewpoint and "how they would become a risk to the system."

Building a prototype that operates during hostile attacks, both purposeful and incidental is what software security is about (Julia, 2008). Software security should be able to protect itself and the network against hackers exploiting and abusing software security flaws. Dependable performance, dependability, compliance, threat resistance, threat tolerance, and threat resistance are all characteristics that should be present in software with built-in security. Security should start with the requirements and should include all of the qualities that make the system safe (Nikhat, Parveen, Khan, and Rizwan, 2015). The level of resilience to, or defense from, assault is referred to as security. One must be knowledgeable about security concerns to provoke security standards. CIA (Confidentiality, Integrity, and Availability) (McGraw, 1999) are the most typical concerns.

·         C: Confidentiality refers to the safeguarding of data against unauthorized disclosure.

·         I: The term "integrity" relates to the prevention of unauthorized data manipulation.

·         A: Availability refers to the prohibition of unlawful information withholding.

Confidentiality means that only the user has access to information, regardless of where it is stored or how it is accessed.

It can be preserved through mechanisms like network access, passwords, fingerprints, cryptography, confidentiality, and morality, while authenticity refers to preventing the consistency and validity of data and processing processes from being altered purposefully, unintentionally, or accidentally. Integrity must be preserved to ensure data and information privacy, security, and dependability. System maintenance and auditing are the mechanisms that ensure integrity. Likewise, availability means that authorized persons have immediate access to data and related assets. Backup data plans, catastrophe planning, and continuity planning are examples of techniques that can keep availability up.

3.      SCOPE

Current structures and benchmarks such as the Capability Maturity Model Integration (CMMI) framework, Team Software Process (TSP), the FAA-iCMM, the Trusted CMM/Trusted Software Methodology (T-CMM/TSM), and the Systems Security Engineering Capability Maturity Model are explained in the innovation and subject matter areas (SSE-CMM). The Team Software Process for Secure Software Development, a Microsoft Trustworthy Computing Software Development Lifecycle (TSPSM-Secure), Correctness by Construction, Rapid Approaches, and the Standard Principles are also featured. To give the reader as much updated knowledge as possible, two new techniques, Software Assurance Maturity Model (SAMM) and Software Security Framework (SSF), were presented.

4.      KEY TERM

There are a few terminologies included in this work that might benefit from a general understanding. These are as follows:

4.1  Process

A process, according to the IEEE, is "a step by step process carried out for a specific goal" (IEEE Std 610.12-1990). A software security process is the collection of operations that go into creating, maintaining, and delivering a safe software platform. Activities do not have to be done in order; they can be done concurrently or iteratively.

4.2  Process Model

A process model is an important set of best standards that may be applied for continuous improvement as well as progress monitoring. The process model describes the properties of processes rather than the processes themselves. Process models typically have a framework or design. Process areas are made up of groups of best practices that contribute to the achievement of similar objectives, and subcategories are made up of related process areas. Supreme procedure copies additionally include a competency or development element that can be applied for analysis and monitoring.

It's critical to comprehend an idea into a product for developing safe software because it's difficult to evaluate the process's flaws and capabilities without doing so. Using shared standards to lead productivity improvements and evaluating processes against a general theory to identify opportunities for improvement is also beneficial. Throughout the software life cycle, processes establish uniform metrics of organizational processes (SDLC). Numerous technology and managerial approaches are identified to use these frameworks.

Since some of these systems were built with privacy in mind from the start, there is an indication that they can do (Herbsleb, 1994 and Goldenson, 2003).

There is no guarantee that firms will follow a specific methodological framework. Ensure that the program they develop is devoid of unintended security flaws as well as harmful code. Nevertheless, following solid tools and methodologies with a focus on better design, improvement processes such as checks and evaluations, use of full analysis processes, suitable use of techniques, risk evaluation, project planning, and team leadership, a company is more likely to form secure software.

4.3  Standards

As illustrations of benchmarks, standards are set by a certain organization, tradition, or universal acceptance. Standards give information that can be used to define procedures.

4.4  Analyses, Reviews, and Evaluations

The three phrases refer to a contrast between an existing process and a benchmark modeling approach or standard. Analyses, reviews, and evaluations are used to determine the competence of a process to enhance it. They aid in determining whether the operations in use are appropriately stated, developed, connected, and managed to satisfy the software product's demands, especially security procedures. They are also significant techniques for identifying and managing vendors' efficiency.

4.5  Software Assurance

SwA is described as " the level of certainty that software is free of flaws, whether they're built-in or accidentally introduced at any stage during the software's life cycle, and that the software performs as intended" [CNSS:2006]. The aim of "software assurance" is defined in the Capability Maturity for Software as "offering proper transparency into the process employed by web applications and into the results being built" (Paulk, 1993).

4.6  Security Assurance

Even though the word "safety guarantee" is frequently utilized, there does not appear to be a consensus on what it means. "Security assurance," according to the Structures and Safety Engineering CMM, is the way of constructing assurance that the security of a product’s requirements is being satisfied. Overall, the phrase refers to the actions, procedures, techniques that deliver trust in a created method's safety qualities and functionalities.

NASA describes a minimal security assurance system as one that provides the following in the Security Assurance portion of its Software Declaration Handbook [NASA].

·         There has been a security risk assessment.

·         For the software applications that have been developed and/or managed, security criteria have been set.

·         For the development and/or maintenance process, security criteria have been specified.

·         Security measures are assessed as part of each software review and/or audit.

·         The system maintenance and corrective action methods ensure that current software is secure, while the change evaluation processes guard against security breaches.

·         The data and applications are adequately protected physically.

Various operations for such specifications, planning, development, and validation, deployment, and management aspects of an SDLC are frequently included in security assurance.

5.      CONTEXT

The subsequent 4 SDLC priority secure software development areas were identified after an assessment of existing procedures, modeling techniques, and guidelines.

5.1  Activities related to Security Engineering

The actions required to develop a secure solution are known as security engineering activities. Elicitation and description of security requirements, a secure design that is based on secure design principles, Examples include the use of static analysis tools, secure reviews and inspections, and security testing. Detailed details of engineering operations can be found in other areas of the Build Security website.

5.2  Assurance of Security Activities

Testing, verification, evaluation plan, artifact summary, and assessments are all examples of assurance activities.

5.3  Organizational and Project Management Processes related to Security

Organizational policies, senior leadership endorsement and supervision, developing functional structure, and other security-related organizational aspects are examples of organizational processes. Project management tasks include distribution of resources and monitoring to assure that security engineering, security assurance, and identifying risks processes are organized, controlled, and recorded.

5.4  Security Risk Identification and Management Activities

The group decides that one of the most important responsibilities in a safe SDLC is identifying and managing potential hazards and that it is the driving force behind subsequent efforts. Security challenges demand additional information security processes, development project management, and system security operations. Build Security's other sections in the website address risk.

6.      DISCUSSION

Whereas the focus of this functional area is concerned with basic techniques, proper deployment of these techniques needs organizational cultural adjustments. Beginning with top managers, the company must endorse the extra training, assets, and actions needed to use a safe project lifecycle. Additionally, every creator must fulfill his or her obligation to participate in such a procedure.

Focusing on the group and product attributes, as well as the security risk of the product, a group, and a company needs to choose the proper software security practices to design a personalized secure software lifecycle.   Governments and industry groups are progressively enforcing cyber security standards on businesses as a result of legal cooperation or as a requirement for consideration as a supplier. Compliant production lifecycles may be adopted more quickly as a result of compliance issues.

REFERENCES

Alberts, C. J., & Dorofee, A. J. (2001). OCTAVE Method Implementation Guide Version 2.0. Volume 2: Preliminary Activities. CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST.Alexander, I. (2003). Misuse cases: Use cases with hostile intent. IEEE software, 20(1), 58-66.

Apvrille A, Pourzadi M (2005) Secure software development by example. IEEE Secur Priv 3(4):10–17

Chandra, S, and R A Khan. "Software Security: A Quantitative Approach." CSI Communication: 19-23. August 2010.

Committee on National Security Systems. National Information Assurance Glossary (CNSS Instruction No. 4009), June 2006.

CORAS: A Platform for risk analysis of security-critical systems. IST-2000 25031. http://www.nr.no/coras/

Dermott JM and Fox C (1999) Using abuse case models for security requirements analysis. Department of Computer Science, James Madison University, pp 55–64

EBIOS (2004) Expression of need and identification of security objectives. DCSSI, France

Ellison RJ (2005) Attack trees. Software Engineering Institute, Carnegie Mellon University

Fabian B, Gurses S, Heisel M, Santen T, Schmidt H (2010) A comparison of security requirement engineering methods. Required Eng 15:7–40

Firesmith DonaldG (2003) Engineering security requirements. J Object Technol 2(1):53–68

G.McGraw, "Software Assurance for Security" IEEE Computer 32(4), pp. 103- 105(April 1999).

Georg G, Ray I, France R (2002) Using aspects to design a secure system, ICECCS. IEEE Computer Society, Washington, pp. 117–126

Giorgini P, Manson G, Mouratidis H, Philip I (2002) A natural extension of tropos methodology for modeling security. Workshop on Agent-oriented methodologies, OOPSLA

Goldenson, D. & Gibson, D. Demonstrating the Impact and Benefits of CMMI: An Update and Preliminary Results (CMU/SEI-2003-SR-009, ADA418491). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.

Guttorm S, Opdahl AL (2005) Eliciting security requirements with misuse cases. Required Eng 10:34–44

Herbsleb, J., Carleton, A., Rozum, J., Siegel, J., & Zubrow, D. Benefits of CMMBased Software Process Improvement: Initial Results (CMU/SEI-94-TR-013, ADA283848). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1994.

IEEE Standards Coordinating Committee. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990). Los Alamitos, CA: IEEE Computer Society, 1990 (ISBN 0738103918 ).

Julia H. Allen, Sean Barnum, Robert J. Ellison, Gary McGraw, Nancy R. Mead: Software Security Engineering: A Guide for Project Managers, Addison Wesley Professional, 2008, pp 6-8

Lipner S, Howard M, (2005) The trustworthy computing security development lifecycle” security engineering and communications, security business and technology unit, Microsoft Corporation

Mayer N, Heymans P, Matulevičius R (2007) Design of a modeling language for Information System Security Risk management, RCIS, pp 1–11

Parveen, Nikhat, Rizwan Beg, and M. H. Khan. "Integrating Security and Usability at Requirement Specification Process." International Journal of Computer Trends and Technology (IJCTT) 10: 236-240

Paulk, M., Curtis, B., Chrissis, M. B. & Weber, C. Capability Maturity Model for Software (Version 1.1) (CMU/SEI-93-TR-024, ADA263403). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993.

The logic behind CRAMM’s assessment of measures of risk and determination of appropriate countermeasures, www.cramm.com. Accessed 23 April 2007

Van Lamsweerde A (2004) Elaborating security requirements by the construction of intentional anti-models, ICSE’04. IEEE Computer Society, Washington, pp 148–157

Ware M, Bowles J, Eastman C (2006) Using the Common criteria to elicit security requirements with use cases. IEEE Computer Society