1 / 19

SHIELDS Project Overview

SHIELDS Project Overview. SHIELDS Consortium. The research leading to these results has received funding from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 215995. Why SHIELDS? Software vulnerabilities are critical problem.

dawn-price
Download Presentation

SHIELDS Project Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SHIELDS Project Overview SHIELDS Consortium The research leading to these results has received funding from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 215995.

  2. Why SHIELDS?Software vulnerabilities are critical problem Vulnerabilities reported by three independent sources • Software vulnerabilities are behind most insecurities • There is continuous growth in software vulnerabilities • Current security methods and tools are failing

  3. Why SHIELDS?Lack of security information for developers Very general overview of the problem targeted at users and system administrators, but nothing concerning how it is manifested in the software or what causes it; doesn’t help detect or eliminate; targeted at users and system administrators Information for risk assessment for users and system administrators; doesn’t help developers Solutions and tools for users and system administrators, but no information on solutions or tools that help developers discover or eliminate this and similar vulnerabilities

  4. Security tool Elimination tool Inspection method Inspection method Security tool Why SHIELDS?Islands of security tools and methods Elimination strategies Inspection rules Testing rules Detection rules Inspection indicators

  5. Security tool Security tool Elimination tool Inspection method Inspection method Elimination strategies Testing rules Inspection rules Detection rules Inspection indicators SHIELDS repository of security models The SHIELDS conceptSharing knowledge about security

  6. Higher assurance for users Tool capabilities become known Tools can remain up-to-date Tools can be updated faster Less duplication of effort One update covers all tools Development resources can be used in more productive ways More secure software Developers get access to more and better security information Security methods and tools may cover more security issues The SHIELDS advantageAssurance – effectiveness – quality

  7. The SHIELDS technologyA new approach to software security • Security models • Tools that use security models • Methods that use security models • Same model used in many ways

  8. The SHIELDS models (I)

  9. The SHIELDS models (II)

  10. The SHIELDS activities (I)

  11. The SHIELDS activities (II) • Security education on vulnerability causes: Activity to raise security awareness of developers through the understanding of the most common reoccurring security issues and their causes (how inadequate requirements, flaws in design, mistakes in code,… can result in vulnerabilities). • Vulnerability Cause Graph (VCG): Graph structure that relates causes to vulnerabilities in a software product. • Security Goal and Vulnerability class identification:to identify both the security goals for the software and the potential vulnerabilities that might occur in it. • Threat models (attack trees and misuse cases): Visually present aspects that can be of threat to a software system or a component of a system. -> Developers use them to prioritize what is to be protected (indicate security goals), identify relevant attacks that exploit commonly found vulnerabilities for this type of system, and show measures on how to mitigate the threats.

  12. The SHIELDS activities (III) • Goal-driven inspections: Manual inspections on different development documents that check for indicators or evidences of the correct implementation of security goals. • Security Goal Indicator Tree (SGIT): Tree-like structure description of the indicators to check for a certain security goal and their relationships. • Guided security inspection checklist: A set of questions in natural language for the inspector to answer during the inspection. • Vulnerability-driven inspections: Manual inspections on different development documents that aim at searching for evidences that indicate that a specific vulnerability is present. For each vulnerability class: • Vulnerability Inspection Diagram (VID): High-level description of the inspection procedure. • Security Inspection Scenario: Description of the inspection procedure in natural language

  13. The SHIELDS activities (IV) • Selecting mitigation strategies: Activity to identify alternative development activities that can be performed in order to prevent vulnerabilities. • Security Activity Graphs (SAG): Tree-like structure description of the different alternatives and their combinations. SAGs are used by developers to select the activities that best fits their corresponding development organization. • Vulnerability cause presence testing: Activity to detectcauses of vulnerabilities in software products. • Vulnerability Detection Conditions (VDC): Formal definition of the information of causes derived from the VCG. VDCs are used through testing tools to automatically determine whether the vulnerability is present in the final implementation.

  14. SHIELDS Developed Tools • While Modelling • GOAT (SHIELDS security modelling tool) • SeaMonster (Security Modeling Software) • While Developing • Flinder (Automated security testing tool that discovers typical security-relevant programming bugs in software) • SecFlow (Static source code analysis tool) • TestGen (Active testing tool that generates test cases based on a functional specification of the software) • TestInv-Code (Passive testing tool that monitors execution traces of an application during run-time) • TestInv-Protocol (Passive testing tool that monitors communication traces of an application during run-time)

  15. Impact of SHIELDS • Better security information for developers • Fewer vulnerabilities • Tools that are better at keeping up with new technologies • Better information for consumers

  16. The SHIELDS consortium Linköpings universitet (Sweden) Stiftelsen SINTEF (Norway) European Software Institute (Spain) Fraunhofer IESE (Germany) Institut TELECOM/TELECOMSudParis (France) Montimage SARL (France) SEARCH-LAB Ltd (Hungary) TXT e-solutions SPA (Italy)

  17. SHIELDSProject data and contact information Project data Project type: Collaborative Project (STREP) Duration: 30 months Project start: January 1, 2008 Project end: June 30, 2009

  18. Contact SHIELDS Project Coordinator Professor Nahid Shahmehri Department of Computer and Information Science Linköpings universitet SE-58183 Linköping SWEDEN @ nahsh@ida.liu.se • +46 13 282066 Dissemination and Exploitation Leader Alessandra Bagnato Corporate Research Division TXT e-solutions Via al Ponte Reale 5 Genova ITALY @ alessandra.bagnato@txt.it  +39 0225771725

  19. SHIELDS Detecting known vulnerablities from within design and development tools Thank you !

More Related