Security Issues Formalization

Slides:



Advertisements
Similar presentations
25 February 2009Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department.
Advertisements

Principles of Computer Security: CompTIA Security + ® and Beyond, Third Edition © 2012 Principles of Computer Security: CompTIA Security+ ® and Beyond,
LIFE CYCLE MODELS FORMAL TRANSFORMATION
A Brief Introduction. Acknowledgements  The material in this tutorial is based in part on: Concurrency: State Models & Java Programming, by Jeff Magee.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
Automated creation of verification models for C-programs Yury Yusupov Saint-Petersburg State Polytechnic University The Second Spring Young Researchers.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
BUSINESS MODELING BY UML PROFILE VISA ISSUING SYSTEM Dražen Brđanin, Slavko Marić Faculty of Electrical Engineering Banja.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 Building with Assurance CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute May 10, 2004.
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Chapter 10 Architectural Design
Proceso kintamybių modeliavimas Modelling process variabilities Donatas Čiukšys.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
Integrating Security Design Into The Software Development Process For E-Commerce Systems By: M.T. Chan, L.F. Kwok (City University of Hong Kong)
A Z Approach in Validating ORA-SS Data Models Scott Uk-Jin Lee Jing Sun Gillian Dobbie Yuan Fang Li.
Introduction to MDA (Model Driven Architecture) CYT.
Computer Security and Penetration Testing
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Structural Modeling. Objectives O Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. O Understand.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Chapter 5 Models and UML Notation for The Object-Oriented Approach.
Lecture 6: Structural Modeling
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
SwA Co-Chair and Task Lead Strategy Session Agenda Technology, Tools and Product Evaluation Working Group Status Briefing Co-Chair(s) Michael Kass (NIST),
Larman chapter 101 Domain Model: Visualizing concepts Larman chapter 10.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Method – Notation 8 Hours.
SE-1021 Software Engineering II
CMSC 345 Defensive Programming Practices from Software Engineering 6th Edition by Ian Sommerville.
Chapter 11 Designing Inputs, Outputs, and Controls.
Modern Systems Analysis and Design Third Edition
Theodore Lawson CSCE548 Student Presentation, Topic #2
Object-Oriented Techniques
Chapter 11 Object-Oriented Design
Modern Systems Analysis and Design Third Edition
Introduction to Unified Modeling Language (UML)
Abstract descriptions of systems whose requirements are being analysed
Concepts used for Analysis and Design
Software Design Methodology
UML Class Diagrams: Basic Concepts
Chapter 2 Database Environment Pearson Education © 2009.
Tools of Software Development
Chapter 19: Building Systems with Assurance
Lecture 22 Inheritance Richard Gesick.
Modern Systems Analysis and Design Third Edition
Introduction to UML.
Chapter 20 Object-Oriented Analysis and Design
ece 627 intelligent web: ontology and beyond
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Modern Systems Analysis and Design Third Edition
Data Model.
Analysis models and design models
Software Design Lecture : 15.
Software requirements
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Soft System Stakeholder Analysis
Chapter 2 Database Environment Pearson Education © 2009.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 Tools of Software Development l 2 types of tools used by software engineers:
Chapter 2 Database Environment Pearson Education © 2009.
Modern Systems Analysis and Design Third Edition
Soft System Stakeholder Analysis
UML Design for an Automated Registration System
Software Architecture & Design
Presentation transcript:

Security Issues Formalization prof. Vladimir Dimitrov Faculty of Mathematics and Informatics University of Sofia, Bulgaria

Weakness (Common Weakness Enumeration - CWE) A type of mistake in software that, in proper conditions, could contribute to the introduction of vulnerabilities within that soft-ware. This term applies to mistakes regardless of whether they occur in implementation, design, or other phases of the SDLC.

Vulnerability (Common Vulnerabilities and Exposures - CVE) An occurrence of a weakness (or multiple weaknesses) within software, in which the weakness can be used by a party to cause the software to modify or access unintended data, interrupt proper execution, or perform incorrect actions that were not specifically granted to the party who uses the weakness.

Attack (Common Attack Pattern Enumeration and Classification - CAPEC) A well-defined set of actions that, if successful, would result in either damage to an asset, or undesirable operation.

CWE, CVE & CAPEC An attacker has to find and exploit a weakness, exposed by a weakness, and realize the vulnerability. These are important concepts that are related but different. A weakness is a static presence existing in software systems -- it might stay in software and never cause any problems until it is exploited by an attacker, and when the attacker finds out the weakness (es) and exploit it (them), the vulnerability of this software is exposed.

Problems What formal methods can be used to help formalize CWEs with required accuracy and precision and at the same time allow for further extensions? To what granularity should CWEs be formalized? Finer granularity means more flexibility (especially when new weaknesses are identified, the extracted commonalities can reduce the re-invent work) but more effort to create them; coarser granularity indicates the easy-to-use weakness items while we need to re-invent the wheel every time. How can the formalized CWEs be used and in which domains? For education and training? To prevent vulnerabilities? To integrate into software IDEs, test tools, and tools that generate test tools? How can an automatic system be constructed to record newly identified vulnerabilities and classify them by CWEs? With better formalization and finer granularity of CWE definitions (which also means limited dictionary for weaknesses, better taxonomy of vulnerabilities), text mining could be the potential technique to mapping CVEs to CWEs at least semi-automatically.

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer Description Summary The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer. Extended Description Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data. As a result, an attacker may be able to execute arbitrary code, alter the intended control flow, read sensitive information, or cause the system to crash.

Semantic Template: Buffer Overflow-related CWEs

CWE-119 Research View

CWE-119 Development View with Inheritance

CWE-119 Development View with Precedence

CWE-119 Relationships

Conclusion One big problem for representation of CWEs in UML diagrams is the need for automatization. The CWEs are represented in XML database, but some information is in text format. The purpose of Semantic templates is to extract formatted and unformatted information from the database. CWEs representation in UML diagrams is good for better visual acceptance by humans. UML is well known notation in the community. There are many tools that support UML. Even more, specialized profiles for CWEs could be developed in UML. It is convenient to generate code from UML in many tools. Such generators could be developed in the UML tools to generate test and verification sequences for CWEs. UML is a notation for software specification. It is formalized with metaclasses by OMG. UML permits the software to be specified at the appropriate level of details in any case. If it is needed OCL can be used for further accuracy. CWEs are organized in abstraction several levels. UML permits such a taxonomy organization with class and object diagrams. The class diagrams organize abstraction levels and the object diagrams stay on the base. UML diagrams could be used for training, education and software development. Their notation is primary developed to humans. UML diagrams can be used as a source for generation of test sequences, verification code etc. that support the software development, testing and verification. Tools that support UML, like RSA, are usually open for that purpose. Tools for semiautomatic identification of vulnerabilities and their classification to the CWEs could be implemented in object-oriented classification style using the artificial intelligence for text recognition and understanding. The work in that direction is huge and many research must be done but Semantic Templates are good starting point.

References MITRE, http://www.mitre.org