DOCSLIB.ORG

Software and System Reliability

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software and System Reliability Handbook of Software Reliability and Security Testing A CSIAC State of the Art Report CSIAC is a DoD Information Analysis Center sponsored by the Defense Technical Information Center Handbook of Software Reliability and Security Testing A CSIAC State of the Art Report CSIAC Report Number 519193 Contract FA8075-12-D-0001 Prepared for the Defense Technical Information Center Prepared By Taz Daughtrey Richard Wisniewski David Nicholls Thomas McGibbon Cyber Security and Information Systems Information Analysis Center Quanterion Solutions Inc. 100 Seymour Road, Suite C102 Utica, NY 13502-1311 Distribution Statement A Approved for public release: distribution is unlimited i REPORT DOCUMENTATION PAGE Form Approved OMB No. 0704-0188 Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 1. REPORT DATE (23-05-2011) 2. REPORT TYPE 3. DATES COVERED (From - To) 15-01-2013 Technical N/A 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER Handbook of Software Reliability and Security Testing FA8075-12-D-0001 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER N/A 6. AUTHOR(S) 5d. PROJECT NUMBER Hugh “Taz” Daughtrey, Richard Wisniewski, David Nicholls, Thomas McGibbon N/A 5e. TASK NUMBER N/A 5f. WORK UNIT NUMBER N/A 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION REPORT Cyber Security and Information Systems Information Analysis Center NUMBER Quanterion Solutions, Inc., 100 Seymour Rd Suite C102 Utica, NY 13502-1311 DAN #519193 9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) Defense Technical Information Center DTIC DTIC/AI 11. SPONSOR/MONITOR’S REPORT 8725 John J. Kingman Rd., STE 0944 Ft. Belvoir, VA 22060 NUMBER(S) 12. DISTRIBUTION / AVAILABILITY STATEMENT Approved for Public Release, Distribution Unlimited 13. SUPPLEMENTARY NOTES 14. ABSTRACT The level of reliability achieved by a DoD system is instrumental to its level of success in today's demanding missions with increasingly limited resources. Each organization must make its own determination as to why and how much reliability is necessary in its designs, as a direct function of what its customer explicitly or implicitly demands. Factors to be considered in the commercial world include the characteristics of the marketplace, the cost of implementing or not implementing a reliability program strategy; and complete knowledge and understanding of customer expectations. As systems, and systems-of-systems, become increasingly complex, the realm of reliability necessarily extends beyond consideration of solely hardware reliability. It must expand to address significant issues pertaining to software reliability and security (the subject of this Handbook) and human factors as a function of human-machine interactions. 15. SUBJECT TERMS Software Reliability, Security, Cyber Security, Software Engineering, Software Testing 16. SECURITY CLASSIFICATION OF: 17. LIMITATION 18. NUMBER 19a. NAME OF RESPONSIBLE PERSON OF ABSTRACT OF PAGES Thomas McGibbon a. REPORT b. ABSTRACT c. THIS PAGE 19b. TELEPHONE NUMBER (include area U U U UU 340 code) 315-351-4203 Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std. Z39.18 ii Table of Contents Page SECTION 1.0: NEED FOR SOFTWARE RELIABILITY................................................................................................... 1 TOPIC 1.1: HOW TO USE THIS HANDBOOK ................................................................................................................... 2 TOPIC 1.2: THE NEED FOR SOFTWARE RELIABILITY .......................................................................................................... 3 SECTION 2.0: SOFTWARE AND SYSTEM RELIABILITY .............................................................................................. 6 TOPIC 2.1: OVERVIEW OF SOFTWARE RELIABILITY ENGINEERING ........................................................................................ 7 TOPIC 2.2: COMPARISON OF HARDWARE AND SOFTWARE RELIABILITY ............................................................................... 13 TOPIC 2.3: SOFTWARE AND SYSTEM RELIABILITY .......................................................................................................... 18 TOPIC 2.4: COMPARISON OF SOFTWARE RELIABILITY AND SOFTWARE SECURITY ASSURANCE ................................................... 20 TOPIC 2.5: SOFTWARE RELIABILITY AND RISK ASSESSMENT ............................................................................................. 24 TOPIC 2.6: RELIABILITY OVER THE SYSTEM LIFE CYCLE ................................................................................................... 28 TOPIC 2.7: IDENTIFICATION OF SYSTEM NEEDS AND FEASIBILITY ANALYSIS .......................................................................... 34 SECTION 3.0: TESTING ......................................................................................................................................... 35 TOPIC 3.1: RELATIONSHIP BETWEEN POLICIES/STANDARDS/GUIDANCE AND SOFTWARE TESTING ............................................ 36 TOPIC 3.2: SYSTEM TEST REQUIREMENTS ................................................................................................................... 40 TOPIC 3.3: SYSTEM OPERATIONAL REQUIREMENTS ................................................................................................... 44 Topic 3.3.1: Operational Profiles ................................................................................................................................46 TOPIC 3.4: TEST STRATEGIES ................................................................................................................................... 51 Topic 3.4.1: Software Reliability Test Strategies ............................................................................................ 51 Topic 3.4.2: Design of Experiments (DOE) ..................................................................................................... 55 TOPIC 3.5: SOFTWARE RELIABILITY TESTING ................................................................................................................ 65 Topic 3.5.1: Overview ................................................................................................................................... 65 Topic 3.5.2: Software Test Coverage Metrics................................................................................................. 68 Topic 3.5.3: Control-Flow Testing .................................................................................................................. 71 Topic 3.5.4: Loop Testing .............................................................................................................................. 77 Topic 3.5.5: Data-Flow Testing ..................................................................................................................... 80 Topic 3.5.6: Transaction-Flow Testing ........................................................................................................... 87 Topic 3.5.7: Domain Testing ......................................................................................................................... 92 Topic 3.5.8: Finite-State Testing .................................................................................................................... 97 Topic 3.5.9: Orthogonal Array Testing ........................................................................................................ 102 Topic 3.5.10: Software Statistical Usage Testing ......................................................................................... 105 Topic 3.5.11: Operational Profile Testing .................................................................................................... 113 Topic 3.5.12: Markov Testing...................................................................................................................... 117 Topic 3.5.13: Optimal Release Time ............................................................................................................ 121 Topic 3.5.14: Security Testing ..................................................................................................................... 123 TOPIC 3.6: RELIABILITY GROWTH AND RELIABILITY DEMONSTRATION/QUALIFICATION TESTING .......................................... 128 Topic 3.6.1: Overview ................................................................................................................................. 128 Topic 3.6.2: Reliability Growth Testing ........................................................................................................ 130 Topic 3.6.2.1: Duane and Crow/AMSAA Models
Load more

Recommended publications
  • An Architect's Guide to Site Reliability Engineering Nathaniel T
    An Architect's Guide to Site Reliability Engineering Nathaniel T. Schutta @ntschutta ntschutta.io https://content.pivotal.io/ ebooks/thinking-architecturally Sofware development practices evolve. Feature not a bug. It is the agile thing to do! We’ve gone from devs and ops separated by a large wall… To DevOps all the things. We’ve gone from monoliths to service oriented to microserivces. And it isn’t all puppies and rainbows. Shoot. A new role is emerging - the site reliability engineer. Why? What does that mean to our teams? What principles and practices should we adopt? How do we work together? What is SRE? Important to understand the history. Not a new concept but a catchy name! Arguably goes back to the Apollo program. Margaret Hamilton. Crashed a simulator by inadvertently running a prelaunch program. That wipes out the navigation data. Recalculating… Hamilton wanted to add error-checking code to the Apollo system that would prevent this from messing up the systems. But that seemed excessive to her higher- ups. “Everyone said, ‘That would never happen,’” Hamilton remembers. But it did. Right around Christmas 1968. — ROBERT MCMILLAN https://www.wired.com/2015/10/margaret-hamilton-nasa-apollo/ Luckily she did manage to update the documentation. Allowed them to recover the data. Doubt that would have turned into a Hollywood blockbuster… Hope is not a strategy. But it is what rebellions are built on. Failures, uh find a way. Traditionally, systems were run by sys admins. AKA Prod Ops. Or something similar. And that worked OK. For a while. But look around your world today.
    [Show full text]
  • Chapter 6 Structural Reliability
    MIL-HDBK-17-3E, Working Draft CHAPTER 6 STRUCTURAL RELIABILITY Page 6.1 INTRODUCTION ....................................................................................................................... 2 6.2 FACTORS AFFECTING STRUCTURAL RELIABILITY............................................................. 2 6.2.1 Static strength.................................................................................................................... 2 6.2.2 Environmental effects ........................................................................................................ 3 6.2.3 Fatigue............................................................................................................................... 3 6.2.4 Damage tolerance ............................................................................................................. 4 6.3 RELIABILITY ENGINEERING ................................................................................................... 4 6.4 RELIABILITY DESIGN CONSIDERATIONS ............................................................................. 5 6.5 RELIABILITY ASSESSMENT AND DESIGN............................................................................. 6 6.5.1 Background........................................................................................................................ 6 6.5.2 Deterministic vs. Probabilistic Design Approach ............................................................... 7 6.5.3 Probabilistic Design Methodology.....................................................................................
    [Show full text]
  • Budgen, Software Design Methods
    David Budgen The Loyal Opposition Software Design Methods: Life Belt or Leg Iron? o software design methods have a correctly means “study of method.”) To address, but future? In introducing the January- not necessarily answer, this question, I’ll first consider D February 1998 issue of IEEE Software,Al what designing involves in a wider context, then com- Davis spoke of the hazards implicit in pare this with what we do, and finally consider what “method abuse,”manifested by a desire this might imply for the future. to “play safe.”(If things go well, you can take the credit, but if they go wrong, the organization’s choice of method can take the blame.) As Davis argues, such a THE DESIGN PROCESS policy will almost certainly lead to our becoming builders of what he terms “cookie-cutter, low-risk, low- Developing solutions to problems is a distinguish- payoff, mediocre systems.” ing human activity that occurs in many spheres of life. The issue I’ll explore in this column is slightly dif- So, although the properties of software-based systems ferent, although it’s also concerned with the problems offer some specific problems to the designer (such as that the use of design methods can present. It can be software’s invisibility and its mix of static and dynamic expressed as a question: Will the adoption of a design properties), as individual design characteristics, these method help the software development process (the properties are by no means unique. Indeed, while “life belt” role), or is there significant risk that its use largely ignored by software engineers, the study of the will lead to suboptimum solutions (the “leg iron”role)? nature of design activities has long been established Robert L.
    [Show full text]
  • Systems Security Engineering Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems
    NIST Special Publication 800-160 VOLUME 1 Systems Security Engineering Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems RON ROSS MICHAEL McEVILLEY JANET CARRIER OREN This publication contains systems security engineering considerations for ISO/IEC/IEEE 15288:2015, Systems and software engineering — System life cycle processes. It provides security-related implementation guidance for the standard and should be used in conjunction with and as a complement to the standard. This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-160v1 NIST Special Publication 800-160 VOLUME 1 Systems Security Engineering Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems RON ROSS Computer Security Division National Institute of Standards and Technology MICHAEL McEVILLEY The MITRE Corporation JANET CARRIER OREN Legg Mason This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-160v1 November 2016 INCLUDES UPDATES AS OF 03-21-2018: PAGE XIII U.S. Department of Commerce Penny Pritzker, Secretary National Institute of Standards and Technology Willie May, Under Secretary of Commerce for Standards and Technology and Director SPECIAL PUBLICATION 800-160, VOLUME 1 SYSTEMS SECURITY ENGINEERING A Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems ________________________________________________________________________________________________ Authority This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems.
    [Show full text]
  • Types of Software Testing
    Types of Software Testing We would be glad to have feedback from you. Drop us a line, whether it is a comment, a question, a work proposition or just a hello. You can use either the form below or the contact details on the rightt. Contact details [email protected] +91 811 386 5000 1 Software testing is the way of assessing a software product to distinguish contrasts between given information and expected result. Additionally, to evaluate the characteristic of a product. The testing process evaluates the quality of the software. You know what testing does. No need to explain further. But, are you aware of types of testing. It’s indeed a sea. But before we get to the types, let’s have a look at the standards that needs to be maintained. Standards of Testing The entire test should meet the user prerequisites. Exhaustive testing isn’t conceivable. As we require the ideal quantity of testing in view of the risk evaluation of the application. The entire test to be directed ought to be arranged before executing it. It follows 80/20 rule which expresses that 80% of defects originates from 20% of program parts. Start testing with little parts and extend it to broad components. Software testers know about the different sorts of Software Testing. In this article, we have incorporated majorly all types of software testing which testers, developers, and QA reams more often use in their everyday testing life. Let’s understand them!!! Black box Testing The black box testing is a category of strategy that disregards the interior component of the framework and spotlights on the output created against any input and performance of the system.
    [Show full text]
  • Practicing a Science of Security a Philosophy of Science Perspective
    Practicing a Science of Security A Philosophy of Science Perspective Jonathan M. Spring Tyler Moore David Pym University College London The University of Tulsa University College London Gower Street 800 South Tucker Drive London WC1E 6BT London WC1E 6BT Tulsa, OK 74104-9700 Alan Turing Institute [email protected] [email protected] [email protected] ABSTRACT Experiments Structured observations of the empirical are untenable world Our goal is to refocus the question about cybersecurity re- Reproducibility Evaluate by repetition, replication, varia- search from ‘is this process scientific’ to ‘why is this scientific is impossible tion, reproduction, and/or corroboration process producing unsatisfactory results’. We focus on five No laws of common complaints that claim cybersecurity is not or can- Mechanistic explanation of phenomena nature not be scientific. Many of these complaints presume views to make nature intelligible No single associated with the philosophical school known as Logical Em- Specialization necessitates translation ontology piricism that more recent scholarship has largely modified or rejected. Modern philosophy of science, supported by mathe- ‘Just’ Both science and engineering are neces- matical modeling methods, provides constructive resources engineering sary to mitigate all purported challenges to a science of security. Table 1: Five common complaints raised by the science of cy- Therefore, we argue the community currently practices a bersecurity community and positive reframing from the phi- science of cybersecurity. A philosophy of science perspective losophy of science literature. suggests the following form of practice: structured observa- tion to seek intelligible explanations of phenomena, evaluating explanations in many ways, with specialized fields (including engineering and forensics) constraining explanations within Its proponents claim a science of security is needed for ongo- their own expertise, inter-translating where necessary.
    [Show full text]
  • Training-Sre.Pdf
    C om p lim e nt s of Training Site Reliability Engineers What Your Organization Needs to Create a Learning Program Jennifer Petoff, JC van Winkel & Preston Yoshioka with Jessie Yang, Jesus Climent Collado & Myk Taylor REPORT Want to know more about SRE? To learn more, visit google.com/sre Training Site Reliability Engineers What Your Organization Needs to Create a Learning Program Jennifer Petoff, JC van Winkel, and Preston Yoshioka, with Jessie Yang, Jesus Climent Collado, and Myk Taylor Beijing Boston Farnham Sebastopol Tokyo Training Site Reliability Engineers by Jennifer Petoff, JC van Winkel, and Preston Yoshioka, with Jessie Yang, Jesus Climent Collado, and Myk Taylor Copyright © 2020 O’Reilly Media. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more infor‐ mation, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Acquistions Editor: John Devins Proofreader: Charles Roumeliotis Development Editor: Virginia Wilson Interior Designer: David Futato Production Editor: Beth Kelly Cover Designer: Karen Montgomery Copyeditor: Octal Publishing, Inc. Illustrator: Rebecca Demarest November 2019: First Edition Revision History for the First Edition 2019-11-15: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781492076001 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Training Site Reli‐ ability Engineers, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.
    [Show full text]
  • A Cybersecurity Testbed for Industrial Control Systems
    A Cybersecurity Testbed for Industrial Control Systems R. Candell, D.M. Anand, and K. Stouffer National Institute of Standards and Technology, Gaithersburg MD, U.S.A [rick.candell, dhananjay.anand, keith.stouffer]@nist.gov Abstract — The National Institute of Standards and Technology (NIST) is developing a cybersecurity testbed for industrial control systems (ICS). The goal of this testbed is to measure the performance of an ICS when instrumented with cybersecurity protections in accordance with practices prescribed by prevailing standards and guidelines. This paper outlines the testbed design and lists research goals, use cases, and performance metrics currently being considered. The paper is also intended to initiate discussion between control and security practitioners – two groups that have had little interaction in the past. Research outcomes from the testbed will highlight specific cases where security technologies impact control performance, as well as motivate methods by which control engineers can leverage security engineering to design control algorithms that extend safety and fault tolerance to include advanced persistent threats. Keywords — industrial control systems, robotics, chemical process control, cybersecurity, industrial security, process resilience, penetration testing, process performance, measurement science, testbed, robotics, robot control, safety, supervisory control and data acquisition (SCADA) I. Introduction Given the increasing interest in security of industrial control systems (ICS) and the evolving nature of advanced persistent threats against critical industrial infrastructure [1], the National Institute of Standards and Technology (NIST) has been actively involved in developing standards for cyber and control systems security via several standards bodies. Examples of such standards and guidelines include [2] and [3]. A research testbed, currently in development at NIST, will provide a platform on which to apply cybersecurity strategies to use cases that are practically relevant to industry.
    [Show full text]
  • Software Design Document 1
    SOFTWARE DESIGN DOCUMENT 1. Introduction The following subsections of the Software Design Document (SDD) should provide an overview of the entire SDD. 1.1 Purpose This subsection should explain the purpose of the SDD and specify the intended audience for it. The SDD described the software structure, software components, interfaces and data necessary for the implementation phase. Each requirement in the SRS should be traceable to one or more design entities in the SDD. 1.2 Scope This subsection should relate the design document to the SRS and to the software to be developed. 1.3 Definitions, Acronyms and Abbreviations This subsection should provide the definitions of all terms, acronyms and abbreviations that are used in the SDD. 2. References This subsection should provide a complete list of all documents referenced in the SDD. It should identify these references by title, report number, date and publishing organization. It should also specify the sources from which these references are available. 3. Attributes of Design Entities There are some attributes common to all entities, regardless of the approach utilized, whether procedural or object-oriented. These are used in subsections 4 and later. 3.1 Identification The name of the entity should be specified. Two entities should not have the same name. 3.2 Type The type attribute should describe the nature of the entity. It may simply name the kind of entity, such as subprogram, module, procedure, process, data item, object etc. Alternatively, design entities can be grouped, in order to assist in locating an entity dealing with a particular type of information.
    [Show full text]
  • Software Tools: a Building Block Approach
    SOFTWARE TOOLS: A BUILDING BLOCK APPROACH NBS Special Publication 500-14 U.S. DEPARTMENT OF COMMERCE National Bureau of Standards ] NATIONAL BUREAU OF STANDARDS The National Bureau of Standards^ was established by an act of Congress March 3, 1901. The Bureau's overall goal is to strengthen and advance the Nation's science and technology and facilitate their effective application for public benefit. To this end, the Bureau conducts research and provides: (1) a basis for the Nation's physical measurement system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to pro- mote public safety. The Bureau consists of the Institute for Basic Standards, the Institute for Materials Research, the Institute for Applied Technology, the Institute for Computer Sciences and Technology, the Office for Information Programs, and the ! Office of Experimental Technology Incentives Program. THE INSTITUTE FOR BASIC STANDARDS provides the central basis within the United States of a complete and consist- ent system of physical measurement; coordinates that system with measurement systems of other nations; and furnishes essen- tial services leading to accurate and uniform physical measurements throughout the Nation's scientific community, industry, and commerce. The Institute consists of the Office of Measurement Services, and the following center and divisions: Applied Mathematics — Electricity — Mechanics — Heat — Optical Physics — Center for Radiation Research — Lab- oratory Astrophysics^ — Cryogenics^ — Electromagnetics^ — Time and Frequency*. THE INSTITUTE FOR MATERIALS RESEARCH conducts materials research leading to improved methods of measure- ment, standards, and data on the properties of well-characterized materials needed by industry, commerce, educational insti- tutions, and Government; provides advisory and research services to other Government agencies; and develops, produces, and distributes standard reference materials.
    [Show full text]
  • Software Error Analysis Technology
    NIST Special Publication 500-209 Computer Systems Software Error Analysis Technology U.S. DEPARTMENT OF COMMERCE Wendy W. Peng Technology Administration Dolores R. Wallace National Institute of Standards and Technology NAT L INST. OF ST4ND & TECH R I.C. NISI PUBLICATIONS A111D3 TTSTll ^QC ' 100 .U57 //500-209 1993 7he National Institute of Standards and Technology was established in 1988 by Congress to "assist industry in the development of technology . needed to improve product quality, to modernize processes, to reliability . manufacturing ensure product and to facilitate rapid commercialization . , of products based on new scientific discoveries." NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S. industry's competitiveness; advance science and engineering; and improve public health, safety, and the environment. One of the agency's basic functions is to develop, maintain, and retain custody of the national standards of measurement, and provide the means and methods for comparing standards used in science, engineering, manufacturing, commerce, industry, and education with the standards adopted or recognized by the Federal Government. As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and applied research in the physical sciences and engineering and performs related services. The Institute does generic and precompetitive work on new and advanced technologies. NIST's research facilities are located at Gaithersburg, MD 20899, and at Boulder, CO 80303.
    [Show full text]
  • Cyber Security Engineering, Bs
    2016-2017 Volgenau School of Engineering CYBER SECURITY ENGINEERING, B.S. 2016 - 2017 Cyber Security Engineering is concerned with the development of cyber resilient systems which include the protection of the physical as well as computer and network systems. It requires a proactive approach in engineering design of physical systems with cyber security incorporated from the beginning of system development. Cyber security engineering is an important quantitative methodology to be used in all industries to include, but not limited to, transportation, energy, healthcare, infrastructure, finance, government (federal, state, and local), and defense. The program is focused on the cyber security engineering of integrated cyber-physical systems. This degree provides a foundation in cyber security engineering, and is most appropriate for students with a strong mathematics and science background. The program is administered by the Dean's Office, Volgenau School of Engineering. Cyber security engineers are part of integrated design and development teams for physical systems that require embedded cyber security design, working with engineers from other disciplines (e.g. civil, mechanical, electrical, systems engineers as well as computer scientists and software engineers). Cyber security engineers are engineers who know technology, but who also have in-depth exposure to the application/domain area. Not only do they provide technological solutions to cyber security problems of engineering systems posed by others, but by having an understanding of the application/domain, they can formulate potential security threats, propose appropriate solutions, and then provide leadership in the design of a system to resist and survive these threats. Because of their interdisciplinary training, cyber security engineers are expected to play an increasing role in attacking some of the most pressing current cyber security issues in the country.
    [Show full text]