Challenges of Software Certification - Article Example

Software Certification (Field Title) Name: ID Number Module Name: Date: Table of Contents Introduction 4 Challenges of Software Certification 6 Software Certification 8 Certifiable Artifacts 9 The Property being certified and the Certification Authority 12 Software Reliability 13 Software Safety 13 Software Validity 14 System Software 15 Software Release Policies 15 Certification Services 15 Current Technology and Advances Required 16 Modular Reasoning and Separation Logic 16 Domain-Specific logics and certified linking 17 Certified and certifying compilation 17 Lightweight formal methods 17 Conclusion 18 Software Certification Introduction Software certification is becoming an important process as go deep into the 21st century. The modern business, company products and the daily working environment revolves around the software certification process. Every time software fails in a business, losses are incurred through low productivity, lost potential sales, lost suppliers, lost customers, lost revenue, corrupted or lost data and expenses involved in bringing the system back and reconstitute and recover data. Despite the great dependence on quality software, organizations are not able to make out which the difference between quality software and fake software when making software procurement decisions. In the modern business world, the reputation of the software, software supplier, software marketing, referral and experiential evidence from friends and published reviews of the software are relied upon when making a decision on which types of software to buy. Unfortunately, published reviews do not usually deal with the quality and reliability of the software most specifically because the reviewers do not usually have a lot of time on their shoulders and the resources required to test the software. Consequently, there are not independent people who offer review of software on which the business will use before a decision to buy the software is made.2,5 This has to change through software certification. There is no doubt that software certification is a powerful instrument that can be used by software consumers to judge the reliability and efficiency of the software in different environments and configurations. A certificate for software is an authoritative tool for marketing and differentiating it from the one by other suppliers and people can attach quantitative reviews of the efficiency of the software in different configurations and environment. Let us therefore look at software certification: Software certification shows the safety and reliability of software systems in a way that can be validated by copyright bodies with minimum confidence in the tools and techniques that are used in the process of certification. Software certification is developed from the available aspects of software validation, assurance and verification strategies but the idea of explicit software certificates comes with software certification. Explicit software certificates refer to all the information needed for independent appraisal of the software owned as property by different people. Proper software certification that will ensure fewer hiccups in the process requires a good software certificate management system (SCMS) which ensures that various certification services are available. The SCMS creates and maintains the connection between different artifacts of the certification system such as engineering data sets, programs and design documents and different types of certificates. The process of SCMS involves checking the validity of the certificates, allowing access to the clear audit paths, making it easy to browse for certification histories and implementation of system certification policies. It also involves the release of policies that are involved in software certification. It is believed that SCMS can be customized to support automatic re-certification of a wide range of artifacts which should be included as an important part of effective software development process. The main impact of customizing the SCMS is to increase the safety and reliability of the software systems by allowing automatic support of the audit process when the program is being assessed.13 With an efficient SCMS, it is easy to get current information on the status of certification for each element in the software system at any given time without delays. It is also easy to check whether audition of the certificates has been done and to work out the certificates that will be valid after the system has been modified. When all this is done, then the system can start automatic incremental re-certification of the software. Challenges of Software Certification Software certification faces challenges because there are no existing systems that have been established to validate and verify the use of the different software hence leading to the certification. For example, there is no established way to validate the use of the flight-control software so the certification of the software by the government, the software must have been developed according a well-documented and detailed process of software development. Most of the time, this is costly in terms of money and time. Therefore, software should be developed in an adaptive system which usually requires specific requirements that are not easy to understand. Another challenge faced by software certification is the prerequisites needed for certification and regulatory approval of fully adaptive system that is to be used for the next generation of hardware that particular software is being used on. These requirements are likely to vary with different applications, organizations, research and with the jeopardy of ethical practices and the success of the software. When one considers the regulatory requirements from the industry standardization board, then the idea of challenges with certification become very clear. The standards used in various industries are overly conservative and therefore outline the ultimate challenge to the certification process of the software. A major problem for the software developed for adaptive system, or even the conventional system is that most of the software designs lack a complete software requirements and specifications that are verifiable. For conventional systems, the software were usually developed and tested in the lab before being released to the field and it was intended to function the same way it did in the laboratory. Most of the time, the fielded system is supposed to learn and change with time in a fully adaptive system.13 The challenge is, the way the software behaves in the field might be different from the way it behaved during the testing phase. The industry advisors then don’t give guidance or standards that tackle the conventional nature of the software adaptive system. The software developers then are left in a fix because they cannot have the software certified because what is in the field in not the same as what was tested in the laboratory.5 It is now evident that the development of a reliable software faces challenges but those specifically related to software3 certification can be summarized as follows: It is hard to develop highly reliable software when diverse techniques have been used in its development. There is decreased certification efforts for interconnected systems and product families of systems Reduction in certification and certification times The relationship between artifacts and certificates Provision of useful information and requirements for certification. The solution provided for these problems is the use of an automated, intelligent and a highly adoptable software certification process that can be integrated into the process of software development.15 Figure 1: Critical Software Development and Verification Process Software Certification Software certification refers to a wide range of informal. Semi-formal and formal approval techniques of explicit compliance with the safety policies, testing, system simulation, human ‘sign offs’ and code reviews and even supporting literature. As a result, there can be different certificates for different software developed for different purposes and the certifications may take different certification mechanisms and techniques. A good Software Certification Management System should have the ability to support different types and mechanisms of certification. For separation of concerns to be guaranteed and scalability to be achieved, certification strategies should be focused on one individual risk factor at a time. As a result, this makes an SCMS to successfully combine different certificates concerned with the same artifact to build a great certificate and in the end provide the consumer with a higher degree of assurance and confidence in the software.14 A software certificate must have all the information needed for free and fair assessment carried out in an independent process while taking into consideration all the claimed artifact properties. Apparently, the actual nature of the software certificates is dependent on the characteristics of the artifact, the claim, the objective of the software and the property. However, a certification process should have a collective view of the required certificates and the verification process. Largely, a certificate is supposed to represent three major aspects of the process of certification I. The Certifiable Artifacts II. The Property being certified III. The Certification Authority Certifiable Artifacts The certifiable artifacts for software certification include the published and manufactured articles of the software such as completed system for the software, production families, code fragments and even the individual components. The supporting non-software components are also part of certifiable artifacts. These include the system designs, documents, component specifications, individual case studies for testing, test plan, engineering and scientific data among others. 15, 14 Most of the time it is possible to find a case where the supporting evidence for the certification of one software is used as an artifact for the certificate of another document. For instance, when the correctness of an individual component of a software is being assessed for certification using the conventional black-box testing, the test scripts and the test harness can be used as supporting evidence for the certification process, similarly, the test harness can also be an artifact for certification by the modern process of code review therefore it becomes an artifact for obtaining another certificate.1 It is very important to have in mind that software certificates for a certain artifact do not just consist of a collection of unstructured data, codes and documents. The certificate usually displays a certificate hierarchy. A certificate Hierarchy is used to establish the trust a client should have in the certificate. Any client software that supports the verification by certificates should always maintain trusted certificates by the certifying body. These certificates then should make it easy to determine the person issuing the certificates who can be trusted and validated. A trusted software certificate can be validated by the software if it is issued by the recognized and validated body. It is possible therefore for a software certificate to be a component of a certificates issued by the certification body as displayed in a certification hierarchy. 15 A large organization can delegate the responsibility of issuing certificates to various different certification associations. This is because; number of required certificates may be too big to be maintained by one certification body. This is because different units of an organization may have different requirements are per the policies. The responsibilities of issuing the certificates among the different organization units can adopt a certificate hierarchy like the one shown in Figure 2 below used for the certification of Red Heart software. 13 Figure 2: Example of a Hierarchy of Certificate Authorities As shown in the example above, a certificate hierarchy is determined by two dimensions independent of each other. i. The internal structure of the certification system ii. The type of certificate The structure of the certification system is usually mirrored in the certificate hierarchy. If the software system is disintegrated into several subsystems and each of the subsystems is made up of a number of elements, then the certificate of the software will directly depend on the certificates of the subsystems involved and indirectly on the certificates of the elements involved. A Software Certification Management System should have the ability to display this structure putting into consideration all the language-specific rules of visibility such as subsystem boundaries and modules that can inhibit the dissemination of changes in the system.14 The type of certificate is second dimension of the certificate hierarchy where a SCMS should be able to generate different types of certificates to be used on different platforms and formats. The planning the required certificates and management of the certificates as well as determination of the formats needed and how planning for renewal, are all important steps in managing the certification system. The following list in not comprehensive: there are different certificates for file-signing, for dual-use in different directories and several subsystem certificates. With the installation of different certificates for a particular subsystem, the required keys and certificates are usually generated. The validity of a certificate is also dependent on the certificates for the supporting evidence or the validating authority. For example, this is happens when a reviewed code can only be validated by a certified software engineer. This stage of certificate hierarchy displays the internal procedures and structure of the organization that has developed the software. A certification system can them make use of the certificate hierarchy for incremental re-certification and auditing. During certification, it is important to determine the certificates that need inspection, recomputation or revalidation after a certificate or an artifact has been modified. The Property being certified and the Certification Authority The conventional forma of software certification addressed a limited range of formal software property. To be realistic, the development of software requires collection of a wide range of opinions and ideas of reliability, validity and safety of the software each with contributions from suitable certification authorities. All these must be supported and verified by a software certification system that is customizable. 14 Software Reliability It is important to verify the reliability of software so that the computer systems can be trusted to work efficiently. Software certification bodies verify the reliability of software if it is able to: 1. Clearly defines the requirements for controlling the software system in case of failure or fault detection, recovery and isolation 2. Provides a detailed review of the process of software development and products needed for error protection in stated of reduced functionality 3. Clearly the process of evaluating and analyzing the defects and derives or defines the maintainability and reliability factors. The techniques used in determination of software reliability are predictive and trending. Predictive reliability of software gives the probability of operation profile of the certifiable software. For example, the prediction that the system using the software has a 4% chance of failing if it operates in the next 50 hours. Trending reliability of software follows the approximate failure of the system to produce a reliability operation profile over specific system. During certification, reliability trending of the software is more appropriate whereas software reliability of the predictive nature is less suitable for software but more suitable for hardware certification. Software Safety A system using software is prone to malfunctioning which may cause injuries, deaths, loss and destruction of important equipment, destruction of the environment and safety of the system including safety of the software. 12 The discipline of verifying the safety of the software involves systematic approach recognizing, analyzing and checking the mitigation of the software and determination of the control standards for the hazards and the hazardous functions such as commands and data to make sure that the software operates safely within the system. Software must be certified for its extent of safety during the concept phase ad before the planning or acquisition of the same.2, 3 Certification of software with respect to safety takes into consideration the following criteria: 1. Exists in a critically safe system as validated by a hazard analysis. Hazard analysis includes: i. Causes a hazard or contributes to it ii. Prevents or mitigates hazards iii. Maintains critical safety functions iv. Redevelops safe commands or data v. Alleviates destruction in case a hazard occurs 2. Produces data and trend analysis that directly result in safety decisions 3. Allows for partial or full validation and verification of the safety critical computer system. Software Validity Software validation is the course of action taken in confirmation of the software’s identity. For networking purposes, the validity of the software involves the identity of the software which can be easily recognized by the clients. Certification is one of those ways of according software validity.12 Software that clients interact with via networks through the connection of a web browser to a server need software authentication. System Software During software certification, the software architecture and hardware platform upon which it is going to perform should be clearly specified. The certificate should clearly define system software to be used including the name of the operating system, the version number and the manufacturer and all the software components including the operating system itself, the compilers and the application software to be used together with it. The hardware platform specification should include the identity and the unique name of the hardware to be used and this includes the name, version and identity of the hardware. Both hardware drivers for both the software and hardware to enable efficient working of the software should be specified and made easily accessible to the users.6 Software Release Policies A release as used in the software certification context refers to the movement of a software artifact into another defined state like system launch, alpha and best phases of testing, system integration and code inspection.4 A release policy properly illustrates the conditions under which an artifact believed in an state that has been adequately certified allowing it to be safely released to another state. There are various release policies that are formulated to explain the different kinds of releases and the equivalent certification prerequisites. Certification Services Software certification service may involve several functions of database maintenance such as storage and retrieval of certificates and incremental re-certification. Specifically, the software certification services involve: certificate construction which happened when there is a specific artifacts, evidence of a claimed property and certification authority. A certification system also edits or revokes a certificate in cases where a certification authority is no longer valid. In addition to this certificate maintenance is also done by the certification system which carries out intelligent re-certification when a significant change has taken place in the course of certification. Auditing is another certificate offered by a certification system by providing full information on the procedures involved and the artifacts needed. The audit can them make part of the certification system’s database Current Technology and Advances Required Modular Reasoning and Separation Logic Modular reasoning is the most common technique used to develop a software verification scale. This type of verification may benefit from top-down approaches that first concentrates on the high-level specification and design and then comes down to the lower tires of the system which are smaller modules of the software.11 The high-level specifications are refined into the real implementation and finally each specific component is certified and linked together to complete the system. Another significant dimension of coming up with software verification scale modular is use of traditional Hoare logics that come up with program specifications with arbitrarily large blueprints.7 Separation logic supports modular reasoning using the specifications of the small elements making up the entire system. The specification of every element must therefore refer to the data structures only affecting the underlying code. Through concise specification of the separation heap and the other reserves, separation logic allows for short yet influential rules for inferential reasoning about shared data structures.7, 8. Domain-Specific logics and certified linking This is the first step towards making the certified software practical by showing that is feasible to do an end-to-end certification process of system software.10. This is used in large software systems, especially low level operating systems which use so many language features and cover a range of abstraction levels. Certified and certifying compilation Most of the work done in verifying the program focuses on the source level-programs which have been written using high-level programs such as C, Java and C+. For these programs to be converted into certified components appropriate for connecting in the certification system, the software developers must prove that the corresponding compiler can be trusted. For instance, CompCert is a certified complier for subset of the C language called the Cm or C minor. By “certified”, compiler, it means that the compiler itself has been proved to be correct. Most of the work on certifying compiler is focused on type-set language sources and only preserve type-safety properties.9 The only challenge is to the extension of the certifying compilation for the preservation of security properties. Lightweight formal methods Most of the time, the development of a large-scale certified software does not need heavy weight verifications of the program. Most of the systems are usually built from modular elements at different levels of abstraction. At the lower levels, the kernel and runtime components are certified and at higher levels, the elements with restricted structures of operation are certified on well defined interfaces.11 The restricted structure uses the type-safe programming languages, high-level in a style that is understandable to tools of static-analysis. Lightweight formal methods can be used to guarantee significant safety properties with reasonable efforts from the programmer. Lightweight formal methods also reduce the cost of building a software certification system. Conclusion Software certification is a very important step in developing a software system. Recertification an incremental certification of software in developed and changed as a requirement for applying the contemporary and evolutionary certification processes that are relevant for a particular certification body and industry. Software developers make it clear that the dependability claim and show that software really certifies the suggested claim. It is important that certification of software does not really warrant that the computer system can be depended on. There should be a separation between depending on the certified software and depending on the software in the working environment.16 References 1. S. Autexier, D. Hutter, T. Mossakowski, and A. Schairer. 2003. The Development Graph Manager AYA (System Description). In Proc. 9th International Conference on Algebraic Methodology And Software Technology (AMAST’02). LNCS 2422, pp. 495–501, 2002. olumbia Accident Investigation Board Report, Volume 1. http://caib.nasa.gov/. 2. E. Denney and B. Fischer. 2005. Formal Safety Certification of Aerospace Software. In Proc. Infotech@Aerospace. AIAA,. Invited talk. 3. E. Denney and B. Fischer. 2005. A Program Certification Assistant Based on Fully Automated Theorem Provers. In Proc. International Workshop on User Interfaces for Theorem Provers, (UITP’05). 4. T. Kelly and R. Weaver, 2004. The Goal Structuring Notation – a Safety Argument Notation. In Proc. DSN Workshop on Assurance Cases: Best Practices, Possible Obstacles, and Future Opportunities, 2004. Programatica Project. www.cse.ogi.edu/PacSoft/projects/programatica. 2004. 5. A.W. Appel. Foundational proof-carrying code. In Proc. 16th Annual IEEE Symposium on Logic in Computer Science, pages 247–258, June 2001. 6. K.W. Brookes. Secure Formatted Information Exchange Gateway Pattern, Version 1.1 (Document Number TS0402) - Section 5.1, Pattern Requirements, April 2010 7. P.W. O’Hearn. Resources, concurrency and local reasoning. In Proc. 15th Int’l Conf. on Concurrency Theory (CONCUR’04), volume 3170 of LNCS, pages 49–67, 2004. 8. S. Ishtiaq and P.W. O’Hearn. BI as an assertion language for mutable data structures. In Proc. 28th ACM Symposium on Principles of Programming Languages, pages 14–26, Jan. 2001. 9. X. Leroy. Formal certification of a compiler back-end or: Programming a compiler with a proof assistant. In Proceedings of the 33rd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL’06), Jan. 2006. 10. X. Feng, Z. Shao, Y. Dong, and Y. Guo. Certifying low-level programs with hardware interrupts and preemptive threads. In Proc. 2008 ACM Conference on Programming Language Design and Implementation, pages 170–182, 2008. 11. J. C. Reynolds. Separation logic: A logic for shared mutable data structures. In Proc. 17th Annual IEEE Symposium on Logic in Computer Science, pages 55–74, July 2002. 12. N. Zeldovich. Securing Untrustworthy Software Using Information Flow Control. PhD thesis, Department of Computer Science, Stanford University, October 2007. 13. Leitner, A., Ciupa, I., Oriol, M., Meyer, B., Fiva, A., "Contract Driven Development = Test Driven Development - Writing Test Cases", Proceedings of ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007, (Dubrovnik, Croatia), September 2007 14. Beizer, Boris (1990). Software Certification Techniques (Second ed.). New York: Van Nostrand Reinhold. pp. 21,430. 15. Myers, Glenford J. (1979). The Art of Software Certification. John Wiley and Sons. pp. 145–146 16. Black, Rex (2008). Advanced Software Certification- Vol. 2: Guide to the ISTQB Advanced Certification as an Advanced Test Manager. Santa Barbara: Rocky Nook Publisher. Read More