DOCSLIB.ORG

Engineering Safe and Secure Software Systems for a Complete Listing of Titles in the Artech House Computer Security Series, Turn to the Back of This Book

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Engineering Safe and Secure Software Systems for a Complete Listing of Titles in the Artech House Computer Security Series, Turn to the Back of This Book Engineering Safe and Secure Software Systems For a complete listing of titles in the Artech House Computer Security Series, turn to the back of this book. Engineering Safe and Secure Software Systems C. Warren Axelrod Library of Congress Cataloging-in-Publication Data A catalog record for this book is available from the U.S. Library of Congress. British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library. Cover design by Vicki Kane ISBN 13: 978-1-60807-472-3 © 2013 ARTECH HOUSE 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. 10 9 8 7 6 5 4 3 2 1 To Judy, David, Nicole, Elisabeth, Evan, and Jolie, with wishes for a safer and more secure world for future generations Contents Preface xvii Foreword xxi 1 Introduction 1 Preamble 1 Scope and Structure of the Book 3 Acknowledgments 4 Endnotes 5 2 Engineering Systems 7 Introduction 8 Some Initial Observations 8 Deficient Definitions 11 Rationale 12 What are Systems? 13 Deconstructing Systems Engineering 16 What Is Systems Engineering? 19 vii viii Engineering Safe and Secure Software Systems Contents ix Systems Engineering and the Systems Engineering Management Process 20 The DoD Text 22 Another Observation 22 More on Systems Engineering 23 The Systems Engineering Process (SEP) 23 Summary and Conclusions 26 Endnotes 26 3 Engineering Software Systems 29 Introduction 29 The Great Debate 31 Some Observations 32 Rationale 33 Understanding Software Systems Engineering 34 Deconstructing Software Systems Engineering 34 What Is Software? 35 What Are Software Systems? 36 Are Control Software Systems Different? 42 What is Software Systems Engineering? 42 The Software Systems Engineering Process 44 Steps in the Software Development Process 44 Omissions or Lack of Attention 48 Nonfunctional Requirements 48 Testing Nonfunctional Attributes 49 viii Engineering Safe and Secure Software Systems Contents ix Verification and Validation 49 Creating Requisite Functional and Nonfunctional Data 52 Resiliency and Availability 55 Decommissioning 56 Summary and Conclusions 56 Endnotes 57 4 Engineering Secure and Safe Systems, Part I 59 Introduction 59 The Approach 60 Security Versus Safety 60 Four Approaches to Developing Critical Systems 63 The Dependability Approach 64 The Safety Engineering Approach 65 The Secure Systems Approach 67 The Real-Time Systems Approach 68 Security-Critical and Safety-Critical Systems 68 Summary and Conclusions 70 Endnotes 70 5 Engineering Secure and Safe Systems, Part 2 73 Introduction 73 Approach 75 Reducing the Safety-Security Deficit 76 Game-Changing and Clean-Slate Approaches 77 A Note on Protection 81 Safety-Security Governance Structure and Risk Management 83 x Engineering Safe and Secure Software Systems Contents xi An Illustration 83 The General Development Life Cycle 84 Structure of the Software Systems Development Life Cycle 86 Life Cycle Processes 89 Governance Structure for Systems Engineering Projects 92 Risks of Security-Oriented Versus Safety-Oriented Software Systems 94 Expertise Needed at Various Stages 95 Summary and Conclusions 95 Endnotes 96 6 Software Systems Security and Safety Risk 99 Introduction 99 Understanding Risk 100 Risks of Determining Risk 100 Software-Related Risks 101 Motivations for Risk Mitigation 103 Defining Risk 104 Assessing and Calculating Risk 105 Threats Versus Exploits 107 Threat Risk Modeling 111 Threats from Safety-Critical Systems 114 Creating Exploits and Suffering Events 116 Vulnerabilities 119 Application Risk Management Considerations 120 Subjective vs. Objective vs. Personal Risk 121 Personalization of Risk 122 x Engineering Safe and Secure Software Systems Contents xi The Fallacies of Data Ownership, Risk Appetite, and Risk Tolerance 122 The Dynamics of Risk 124 A Holistic View of Risk 125 Summary and Conclusions 126 Endnotes 128 7 Software System Security and Safety Metrics 131 Introduction 131 Obtaining Meaningful Data 133 Defining Metrics 133 Differentiating Between Metrics and Measures 135 Software Metrics 138 Measuring and Reporting Metrics 140 Metrics for Meeting Requirements 143 Risk Metrics 146 Consideration of Individual Metrics 146 Security Metrics for Software Systems 150 Safety Metrics for Software Systems 151 Summary and Conclusions 152 Endnotes 153 8 Software System Development Processes 157 Introduction 157 Processes and Their Optimization 158 Processes in Relation to Projects and Products/Services 159 xii Engineering Safe and Secure Software Systems Contents xiii Some Definitions 161 Chronology of Maturity Models 164 Security and Safety in Maturity Models 165 FAA Model 165 The +SAFE V1.2 Extension 167 The +SECURE V1.3 Extension 167 The CMMI® Approach 167 General CMMI® 167 CMMI® for Development 168 Incorporating Safety and Security Processes 169 +SAFE V1.2 Comparisons 169 +SECURE V1.2 Comparisons 172 Summary and Conclusions 173 Endnotes 175 9 Secure SSDLC Projects in Greater Detail 177 Introduction 177 Different Terms, Same or Different Meanings 178 Creating and Using Software Systems 180 Phases and Steps of the SSDLC 182 Summary and Conclusions 191 Endnotes 193 10 Safe SSDLC Projects in Greater Detail 195 Introduction 195 Definitions and Terms 196 Hazard Analysis 198 Software Requirements Hazard Analysis 199 Top-Level Design Hazard Analysis 200 Detailed Design Hazard Analysis 201 Code-Level Software Hazard Analysis 201 xii Engineering Safe and Secure Software Systems Contents xiii Software Safety Testing 201 Software/User Interface Analysis 202 Software Change Hazard Analysis 203 The Safe Software System Development Lifecycle 204 Combined Safety and Security Requirements 207 Summary and Conclusions 208 Endnotes 209 11 The Economics of Software Systems’ Safety and Security 211 Introduction 211 Closing the Gap 212 Technical Debt 214 Application of Technical Debt Concept to Security and Safety 215 System Obsolescence and Replacement 217 The Responsibility for Safety and Security by Individuals and Groups 218 Basic Idea 218 Extending the Model 219 Concept and Requirements Phase 219 Design and Architecture Phase 222 Development 223 Verification 224 Validation 224 Deployment, Operations, Maintenance, and Technical Support 225 Decommissioning and Disposal 226 Overall Impression 226 Methods for Encouraging Optimal Behavior 226 Pricing 227 Chargeback 227 Costs and Risk Mitigation 228 Management Mandate 228 xiv Engineering Safe and Secure Software Systems Contents xv Legislation 229 Regulation 229 Standards and Certifications 229 Going Forward 230 Tampering 231 Tamper Evidence 231 Tamper Resistance 232 Tamperproofing 232 A Brief Note on Patterns 234 Conclusions 236 Endnotes 238 Appendix A: Software Vulnerabilities, Errors, and Attacks 239 Ranking Errors, Vulnerabilities, and Risks 240 The OWASP Top Security Risks 241 The CWE/SANS Most Dangerous Software Errors 244 Top-Ranking Safety Issues 244 Enumeration and Classification 246 WASC Threat Classification 248 Summary and Conclusions 250 Endnotes 250 Appendix B: Comparison of ISO/IEC 12207 and CMMI®-DEV Process Areas 253 Appendix C: Security-Related Tasks in the Secure SSDLC 257 Task Areas for SSDLC Phases 258 Involvement by Teams and Groups for Secure SSDLC Phases 262 xiv Engineering Safe and Secure Software Systems Contents xv A Note on Sources 288 Endnotes 288 Appendix D: Safety-Related Tasks in the Safe SSDLC 289 Task Areas for Safe SSDLC Phases 289 Levels of Involvement 309 A Note on Sources 309 Endnotes 313 About the Author 315 Index 317 Preface The best laid plans o’ Mice an’ Men, Gang oft agley ... —Robert Burns, To a Mouse The initial concept for this book arose some 3 to 4 years ago. However, it was quite different from how the book turned out. I had spent much of the previous decade working on application security, particularly software assur- ance. Several years ago, I had the good fortune of being the technical lead on a software assurance initiative for the banking and finance sector, supported by the Financial Services Technology Consortium. The first phase of the proj- ect provided insights from thought leaders from independent software vendors (ISVs), information security tools and services vendors, industry and profes- sional associations, academia, and a number of leading financial institutions. A collection of state-of-the-art practices was assembled, with the intention of us- ing the “best” approaches for assuring the quality of software through industry- sponsored testing. This work provided a substantial amount of the research that was behind the BITS publication Software Assurance Framework [1]. The ultimate goal of the software assurance initiative was to establish a state-of-the-art testing facility for the financial services industry using methods, tools, and services chosen from the initial research. Unfortunately, the financial meltdown of 2008 interceded. Various mergers and restructurings took place, so that attention was turned to other more pressing matters. The financial services industry
Load more

Recommended publications
  • 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]
  • 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]
  • 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]
  • 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]
  • Software Tamperproofing
    Software Tamperproofing7 To tamperproof a program is to ensure that it “executes as intended,” even in the presence of an adversary who tries to disrupt, monitor, or change the execution. Note that this is different from obfuscation, where the intent is to make it difficult for the attacker to understand the program. In practice, the boundary between tam- perproofing and obfuscation is a blurry one: A program that is harder to understand because it’s been obfuscated ought also be more difficult to modify! For example, an attacker who can’t find the decrypt() function in a DRM media player because it’s been thoroughly obfuscated also won’t be able to modify it or even monitor it by setting a breakpoint on it. The dynamic obfuscation algorithms in Chapter 6 (Dynamic Obfuscation), in particular, have often been used to prevent tampering. In this book, we take the view that a pure tamperproofing algorithm not only makes tampering difficult but is also able to detect when tampering has occurred and to respond to the attack by in some way punishing the user. In practice, tamperproofing is always combined with obfuscation: 1. If you both obfuscate and tamperproof your code, an attacker who, in spite of the tamperproofing, is able to extract the code still has to de-obfuscate it in order to understand it; 2. Code that you insert to test for tampering or effect a response to tampering must be obfuscated in order to prevent the attacker from easily discovering it. 401 402 Software Tamperproofing Watermarking and tamperproofing are also related.
    [Show full text]
  • Demystifying Anti-Repackaging on Android a ∗ a a a Alessio Merlo , , Antonio Ruggia , Luigi Sciolla and Luca Verderame
    You Shall not Repackage! Demystifying Anti-Repackaging on Android a < a a a Alessio Merlo , , Antonio Ruggia , Luigi Sciolla and Luca Verderame aDIBRIS - University of Genoa, Via Dodecaneso, 35, I-16146, Genoa, Italy. ARTICLEINFO ABSTRACT Keywords: App repackaging refers to the practice of customizing an existing mobile app and redistributing Android Security it in the wild. In this way, the attacker aims to force some mobile users to install the repackaged App Security (likely malicious) app instead of the original one. This phenomenon strongly affects Android, Anti-repackaging techniques where apps are available on public stores, and the only requirement for an app to execute properly Attacks to Anti-repackaging is to be digitally signed. Anti-tampering Anti-repackaging techniques try counteracting this attack by adding logical controls in the app at compile-time. Such controls activate in case of repackaging and lead the repackaged app to fail at runtime. On the other side, the attacker must detect and bypass the controls to repackage safely. The high-availability of working repackaged apps in the Android ecosystem suggests that the attacker’s side is winning. In this respect, this paper aims to bring out the main issues of the current anti-repackaging approaches. The contribution of the paper is three-fold: 1) analyze the weaknesses of the current state-of-the-art anti-repackaging schemes (i.e., Self-Protection through Dex Encryption, AppIS, SSN, SDC, BombDroid, and NRP), 2) summarize the main attack vectors to anti-repackaging techniques composing those schemes, and 3) show how such attack vectors allow circumventing the current proposals.
    [Show full text]
  • Systems Security Engineering Fact Sheet
    The MITRE Corporation Systems Security Engineering The MITRE Corporation is using Systems Security Engineering (SSE) to ensure the U.S. Air Force fields and sustains resilient capabilities that provide mission assurance against evolving threats. SSE uses scientific and engineering principles to deliver assured system-level protection via a single, full-system/full life cycle view of system security. The Challenge Requirements DMS* Cyber attacks, and our ability to effectively deal with them, impact Cryptography Program our nation’s infrastructure, military Software Protection Assurance capabilities, and commercial and military industry partners. Cyber Anti- HW Supply Chain Risk Tamper technology is thoroughly embed- Assurance Management ded into everything we engineer, including both business and weap- Sustainment Other Information ons systems. The historical ways Assurance in which we acquire, operate, and *Diminishing Manufacturing Sources sustain our systems must change Typical security engineering approach: “As Is” because, given time, sophisticated and persistent attackers will get in. Holistic, integrated, program protection The Solution Systems Security Engineering (SSE) New thinking in the applica- tions of systems engineering is Systems Security Engineering Engineering (SSE) Instructions for required in the face of evolving CPI Identification Engineering threats. MITRE is working with Instructions for SSE Integrated our sponsors to address these Technical Process challenges in a holistic manner (SITP) Anti-Tamper that allows the
    [Show full text]
  • 2019 Doctor's Programs in Central South University
    2019 Doctor’s Programs in Central South University School Major Research Field Language Duration School of Marxism Marxism Basic Principle of Marxism Chinese 4 year School of Marxism Marxism Sinicization of Marxism Chinese 4 year School of Marxism Marxism Marxist Studies Abroad Chinese 4 year School of Marxism Marxism Basic Problem of Modern Chinese history Chinese 4 year School of Public Administration Philosophy Marxist Philosophy Chinese 4 year School of Public Administration Philosophy Chinese Philosophy Chinese 4 year School of Public Administration Philosophy Foreign Philosophy Chinese 4 year School of Public Administration Philosophy Ethics Chinese 4 year School of Public Administration Philosophy Aesthetics Chinese 4 year School of Public Administration Philosophy Philosophy of Science and Technology Chinese 4 year School of Public Administration Philosophy Management Philosophy Chinese 4 year School of Public Administration Sociology Theoretical Sociology Chinese 4 year School of Public Administration Sociology Applied Sociology Chinese 4 year School of Public Administration Sociology Public Administration and Social Policy Chinese 4 year School of Public Administration Sociology Social Work Chinese 4 year School of Public Administration Public Management Urban and Local Governance Chinese 4 year School of Public Administration Public Management Public Security and Hazard Governance Chinese 4 year School of Public Administration Public Management Social Organizations and Public Policy Chinese 4 year School of Public Administration
    [Show full text]
  • Security Requirements Reusability and the SQUARE Methodology
    Security Requirements Reusability and the SQUARE Methodology Travis Christian Faculty Advisor Nancy Mead September 2010 TECHNICAL NOTE CMU/SEI-2010-TN-027 CERT® Program Unlimited distribution subject to the copyright. http://www.sei.cmu.edu This report was prepared for the SEI Administrative Agent ESC/XPK 5 Eglin Street Hanscom AFB, MA 01731-2100 The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. This work is sponsored by the U.S. Department of Defense. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense. Copyright 2010 Carnegie Mellon University. NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN ―AS-IS‖ BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and ―No Warranty‖ statements are included with all reproductions and derivative works. External use. This document may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission.
    [Show full text]
  • Systems Security Engineering Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems
    Draft NIST Special Publication 800-160 VOLUME 2 Systems Security Engineering Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems RON ROSS RICHARD GRAUBART DEBORAH BODEAU ROSALIE MCQUAID This document is a supporting publication to the NIST systems security engineering guidance provided in Special Publication 800-160, Volume 1. The content was specifically designed to PRE-RELEASE DRAFT be used with and to complement the flagship systems security NOT FOR DISTRIBUTION engineering publication to support organizations that require cyber resiliency as a property or characteristic of their systems. The goals, objectives, techniques, implementation approaches, and design principles that are described in this publication are an integral part of a cyber resiliency engineering framework and are applied in a life cycle-based systems engineering process. Draft NIST Special Publication 800-160 VOLUME 2 Systems Security Engineering Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems RON ROSS Computer Security Division National Institute of Standards and Technology RICHARD GRAUBART DEBORAH BODEAU ROSALIE MCQUAID Cyber Resiliency and Innovative Mission Engineering Department The MITRE Corporation March 2018 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology DRAFT NIST SP 800-160, VOLUME 2 SYSTEMS SECURITY ENGINEERING CYBER RESILIENCY CONSIDERATIONS FOR THE ENGINEERING OF TRUSTWORTHY SECURE SYSTEMS ________________________________________________________________________________________________________________________________________________ Authority This publication has been developed by the National Institute of Standards and Technology 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.
    [Show full text]
  • Chapter 321 Motor Vehicles and Law of the Road
    1 MOTOR VEHICLES AND LAW OF THE ROAD, Ch 321 CHAPTER 321 MOTOR VEHICLES AND LAW OF THE ROAD Referred to in §7.10, 27A.1, 81.1, 103A.55, 123.46, 123.47, 135C.33, 232.8, 307.27, 312.1, 312.7, 321A.3, 321E.29, 321F.8, 321H.2, 321H.4A, 321I.1, 321I.31, 321J.4B, 321J.20, 321M.1, 321M.2, 321M.6, 322.2, 322.4, 322.9, 322.29, 322A.1, 322C.4, 322C.6, 326.5, 326.6, 326.11, 326.12, 326.22, 326.30, 331.362, 422.11N, 423.1, 423B.4, 435.26A, 462A.33, 516E.1, 535.2, 554.9311, 554.9503, 554.13104, 602.8106, 690.2, 692.1, 692A.101, 707.6A, 714.2, 725.1, 805.6, 805.8A(14)(i), 805.9, 805.16, 809.1, 809A.3, 811.9, 903.1, 910.1 Fines doubled for moving traffic violations occurring in road work zones; §805.8A, subsection 14, paragraph i GENERAL PROVISIONS 321.23A Affidavit of correction. 321.24 Issuance of registration and 321.1 Definitions of words and phrases. certificate of title. 321.1A Presumption of residency. 321.25 Application for registration and 321.2 Administration and enforcement. title — cards attached. 321.3 Powers and duties of director. 321.26 Multiple registration periods and 321.4 Rules. adjustments. 321.5 Duty to obey. 321.27 Implementation of twelve-month 321.6 Reciprocal enforcement — patrol registration period. Repealed beats. by 97 Acts, ch 108, §49. 321.7 Seal of department. 321.28 Failure to register.
    [Show full text]
  • An Introduction to Computer Security: the NIST Handbook U.S
    HATl INST. OF STAND & TECH R.I.C. NIST PUBLICATIONS AlllOB SEDS3fl NIST Special Publication 800-12 An Introduction to Computer Security: The NIST Handbook U.S. DEPARTMENT OF COMMERCE Technology Administration National Institute of Standards Barbara Guttman and Edward A. Roback and Technology COMPUTER SECURITY Contingency Assurance User 1) Issues Planniii^ I&A Personnel Trairang f Access Risk Audit Planning ) Crypto \ Controls O Managen»nt U ^ J Support/-"^ Program Kiysfcal ~^Tiireats Policy & v_ Management Security Operations i QC 100 Nisr .U57 NO. 800-12 1995 The 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 manufacturing processes, to ensure product reliability . 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 develops measurement techniques, test methods, standards, and 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]