O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY A Systems Development and Implementation Study for 21st Century Software and Security Third.

Slides:



Advertisements
Similar presentations
Modeling and Simulation By Lecturer: Nada Ahmed. Introduction to simulation and Modeling.
Advertisements

Basic guidelines for the creation of a DW Create corporate sponsors and plan thoroughly Determine a scalable architectural framework for the DW Identify.
Lecture 5 Themes in this session Building and managing the data warehouse Data extraction and transformation Technical issues.
Software Engineering Techniques for the Development of System of Systems Seminar of “Component Base Software Engineering” course By : Marzieh Khalouzadeh.
What is Software Engineering? And why is it so hard?
Software Quality Metrics
The Architecture Design Process
June 1, 2004Computer Security: Art and Science © Matt Bishop Slide #18-1 Chapter 18: Introduction to Assurance Overview Why assurance? Trust and.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Computer Security: Principles and Practice
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
DITSCAP Phase 2 - Verification Pramod Jampala Christopher Swenson.
Stephen S. Yau CSE , Fall Security Strategies.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
Cloud Usability Framework
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
Information Technology Audit
Computer Simulation A Laboratory to Evaluate “What-if” Questions.
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
Resiliency Rules: 7 Steps for Critical Infrastructure Protection.
SEC835 Database and Web application security Information Security Architecture.
O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY 1.
Incident Response Mechanism for Chemical Facilities By Stephen Fortier and Greg Shaw George Washington University, Institute for Crisis, Disaster and Risk.
Dr. Tom WayCSC What is Software Engineering? CSC 4700 Software Engineering Lecture 1.
CPIS 357 Software Quality & Testing I.Rehab Bahaaddin Ashary Faculty of Computing and Information Technology Information Systems Department Fall 2010.
CLEANROOM SOFTWARE ENGINEERING.
Security Baseline. Definition A preliminary assessment of a newly implemented system Serves as a starting point to measure changes in configurations and.
“Assuring Reliable and Secure IT Services”. IT Redundancy: Its Value How much reliability to buy? Customer Service impacted as a result of 15 minutes.
The Security Analysis Process University of Sunderland CSEM02 Harry R. Erwin, PhD.
Software Engineering ‘The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and.
VTT-STUK assessment method for safety evaluation of safety-critical computer based systems - application in BE-SECBS project.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
ITEC 3220M Using and Designing Database Systems
An Introduction to Information Security Why there’s more to hide than you might think and why hiding it is a lot tougher than you ever dreamed of in your.
Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution.
Software Engineering Lecture # 17
1 Martin Zralý: ENTERPRISE MANAGEMENT CONTROL Department of Enterprise Management and Economics Faculty of Mechanical Engineering, Czech Technical University.
IRM304 CDR Course Manager: Denny Involved Competency Leads: 26 (Cybersecurity)-Denman, 19 (Measurement)-Denny, 7 (DBS)-Corcoran [Capability Planning],
Modeling and simulation of systems Model building Slovak University of Technology Faculty of Material Science and Technology in Trnava.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
Urban Infrastructure and Its Protection Responding to the Unexpected Interest Group Report Group Members G. Giuliano (USC), Jose Holguin-Veras (CUNY),
Combining Theory and Systems Building Experiences and Challenges Sotirios Terzis University of Strathclyde.
1 Discovering Robust Knowledge from Databases that Change Chun-Nan HsuCraig A. Knoblock Arizona State UniversityUniversity of Southern California Journal.
INFORMATION SYSTEMS FOR MANAGEMENT. Agenda Information system project Organization analysis.
Database Administration
23 July 2003 PM-ITTS TSMOTSMO Information Assessment Test Tool (IATT) for IO/IW Briefing by: Darrell L Quarles Program Director U.S. Army Threat Systems.
Lesson 19-E-Commerce Security Needs. Overview Understand e-commerce services. Understand the importance of availability. Implement client-side security.
A Metrics Program. Advantages of Collecting Software Quality Metrics Objective assessments as to whether quality requirements are being met can be made.
1 V&V Needs for NextGen of 2025 and Beyond A JPDO Perspective Maureen Keegan JPDO Integration Manager October 13, 2010.
O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY 1 Ideas on a Framework and Methods for Estimating the Benefits of Government- Sponsored.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 15a: Product Metrics for Software Software Engineering: A Practitioner’s Approach, 6/e Chapter.
SOFTWARE ENGINEERING. Objectives Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis.
Introduction and Overview of Information Security and Policy By: Hashem Alaidaros 4/10/2015 Lecture 1 IS 332.
Slide 1 Security Engineering. Slide 2 Objectives l To introduce issues that must be considered in the specification and design of secure software l To.
Chapter 19: Building Systems with Assurance Dr. Wayne Summers Department of Computer Science Columbus State University
Emerging and Evolving Cyber Threats Require Sophisticated Response and Protection Capabilities  Advanced Algorithms  Cyber Attack Detection and Machine.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
©Ian Sommerville 2000Dependability Slide 1 Chapter 16 Dependability.
Detecting Undesirable Insider Behavior Joseph A. Calandrino* Princeton University Steven J. McKinney* North Carolina State University Frederick T. Sheldon.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
Computer Security: Principles and Practice First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown Chapter 17 – IT Security.
An Iterative Method For System Integration
Introduction for the Implementation of Software Configuration Management I thought I knew it all !
Security Engineering.
Chapter 19: Building Systems with Assurance
Strayer University at Arlington, VA
Luca Simoncini PDCC, Pisa and University of Pisa, Pisa, Italy
Presentation transcript:

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY A Systems Development and Implementation Study for 21st Century Software and Security Third Cyber Security and Information Infrastructure Research Workshop May 2007 Andrew Loebl, James Nutaro, and Teja Kuruganti Oak Ridge National Laboratory Rajanikanth Jammalamadaka University of Arizona

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY This work was inspired by the lead author’s experience with projects implementing the Revolution in Military Affairs. This concept development was not funded by any combination of work related to any of these projects.

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Complex (not merely complicated), continuously evolving, interdependent elements that exhibit functionality far beyond our current “system of systems” concepts. Design and implementation merge with updates and configuration management. Systems operate naturally within a domain of constant conflict and failure while delivering intended results. * May not be distinguishable as hardware or software What Is A Modern ‘Software’ * System?

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Research: Human Attributes Respected Machine Attributes Respected Computational Emergence Foundations for Analysis and Design Adaptive Infrastructure Adaptive and Predictable System Quality Policy, Acquisition, and Management Generation Characteristics: Fast and Correct Development Ultra large-, ultra small-scale Ultra high-quality, and/or ultra high consistency Beyond complexity and cost limits of currently available hardware and education Moore was correct 20 th Century technology, concepts, and methods will not suffice Shaping the Future of Modern Systems

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Imbedded systems are rapidly replacing desktop systems for critical applications Imbedded systems are becoming more powerful and more flexible Imbedded systems will be the invisible systems of the future, with no owner, no administrator, no upgrades or patches, ubiquitous (some negatives here), not stealthy as objective Modern Systems Attributes include; Networked, Imbedded

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Vulnerable systems will be difficult to locate, and impossible to “fix” Attackers will use imbedded systems to move silently through the network Our current work in network security does not handle this new paradigm well At risk will be everything from consumer products to critical infrastructures Implications of Network Imbedded Systems

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Modern Applications Systems Will Be Developed with A Discipline Practiced Only in the Earliest Years of Systems Development Computational Methods Formalized: Provable solutions Mathematically verifiable Numerically and computationally closed to insertion or extraction tested piecemeal Formal Development Framework(s) Standards Evolutionary development Model based development Quantifiable definitions of performance metrics Functional/operational decomposition Completeness Security/integrity

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Motivating Factors for Analyzing Security and Information Assurance Requirements for Digitally Based Systems  Complexity  Expectations  Reliability  Pervasiveness  Ubiquity  Integration

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Characteristics for a Preliminary Model for Information Assurance and Systems Security  Security related requirements analysis executed  Security and performance requirements empirically understood  Marginal additional assurance of measures considered better understood  Cost consequences in two dimensions better understood

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Notional Vulnerability Model Offered for Illustration  Only singular threats considered  Illustrate specification needed to inform requirements determination and design decisions  Expected operational life time of a threat  Appraise performance metrics for essential security processes  Describes expected operational life-time of a threat in terms of; identification and elimination

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY A Probabilistic Model Formulation  D(td) denotes the probability of identifying the attack within the time interval [0, td] after the attack has begun.  [K(t)|D(td)] is the conditional probability of neutralizing the attack at time t given that the attack was identified at time td.  Dc(td) denotes the probability of not identifying the attack within the time interval [0, td]  [K(t)|Dc(td)] denotes the probability of neutralizing the attack before it is identified  K(t) is probability of neutralizing the attack after a time t, as described by Baye’s theorem as K(t) = [K(t)|D(td)]D(td) + [K(t)|Dc(td)]Dc(td)  [K(t)|Dc(td)] = 0. Therefore, K(t) is K(t) = [K(t)|D(td)]D(td) (The expected lifetime of an attack.)

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Notional (cont’d)  k(t) denotes the probability density function of K(t) This is the quantified vulnerability

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Example 1; GPS Jamming  D(td) denotes the time, in minutes, to detect jammer,  [K(t)|D(td)] is a random variable denoting the time, again in minutes, to kill jammer following detection  D(td) is a triangular distribution with [0, 60] minutes as end points and a mode of 30  [K(t)|D(td)] is a triangular distribution with [0, 10] minutes as end points and a mode of 5 minutes

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Example 1; GPS Jamming (con’t)  K(t) time needed to kill the jammer is expected attack lifetime is = 30 minutes

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Empirical Understanding Is Valuable  Other distributions of jammer detection and jammer elimination capabilities evaluated in simulations  Adequacy of a requirement to detect within a critical time period can be evaluated  Fundamental relationship between detection and elimination can be studied  Cost to protect against jamming for which durations can be evaluated  Cost to protect against jamming versus other independent threats, like denial of service, can be evaluated  Through and empirical determination, a host of assumptions and scenarios can be evaluated  With experience, other threats can be evaluated, but our notional model must be improved

O AK R IDGE N ATIONAL L ABORATORY U. S. D EPARTMENT OF E NERGY Conclusions  research needed to develop a quantitative, model based, requirements analysis methodology for security and assurance of vulnerable systems and information for many classes of threat  methods will help produce testable, model based requirements that contribute to security and assurance  requirements thus produced can be validated  validations and extents can be communicated clearly to stakeholders and developers, to provide a objective bases for system verification.  significant reduction in lifetime system costs can accrue  through a quantifiable understanding of requirements and effective, but not merely redundant, application of measures  extent of experimental development needed to combine and improve measures  help to inform decision makers about realistic system performance expectations  ensure that performance expectations are met through more adequate and less expensive system verification, and  reduce system maintenance costs for this assurance and security purpose.