Smals research 'Secure Application Development Lifecycle - An end to end methodology by David Tillemans (Smals)
Upcoming SlideShare
Loading in...5
×
 

Smals research 'Secure Application Development Lifecycle - An end to end methodology by David Tillemans (Smals)

on

  • 939 views

Seminar 'Secure Application Development Lifecycle - An end to end methodology by David Tillemans (Smals) during Infosecurity.be 2011

Seminar 'Secure Application Development Lifecycle - An end to end methodology by David Tillemans (Smals) during Infosecurity.be 2011

Statistics

Views

Total Views
939
Views on SlideShare
891
Embed Views
48

Actions

Likes
0
Downloads
37
Comments
0

1 Embed 48

http://www.infosecurity.be 48

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Smals research 'Secure Application Development Lifecycle - An end to end methodology by David Tillemans (Smals) Smals research 'Secure Application Development Lifecycle - An end to end methodology by David Tillemans (Smals) Presentation Transcript

    • Auteur: David Tillemans
    • 20/03/11About Smals vzw-asblOne of Belgiums largest ICT-organisations: 1660 people"ICT for Society" Work: ex. Dimona-DmfA Salary & labour prestations Health: ex. eHealth-platform Secure exchange of medical data in Belgium Family life: ex. VESTA Home care for elderly (financial / operational support)High priority for ICT Security & Privacy 2
    • 20/03/11Web Project Life Cycle• An idea?• Analysis of functional requirements• Design of the architecture• Implementation  Writing of the source code  Java  C#  ...  Using a framework 3
    • 20/03/11Web Project Life Cycle• Functional testing• Deployment in production• ... (2 years go by)• Hacker comes by  Breaks the application  gives advise  publishes on the internet  steals information  steals money 4
    • 20/03/11What about security ...• Idea?  has no security requirements ... (if it is not a security solution)• Analysis of functional requirements  Non-functional  Architecture solves this ...• Design of the architecture  Non-functional requirements  Network infrastruture solves this ...• Developer  Is not written in design & analysis  No security guidelines 5
    • 20/03/11What about security ...• Functional testing  Tests are performed in the boundaries  No security is considered in tests• Deployment to Production  No security considered in deployment  Network operations solves this ... 6
    • 20/03/11What about security ...• Hacker comes by  Analyses the security of the web application in relation to the business requirements  Reviews the architecture  Verifies the security in the development  Checks the security of the deployment• Hacks the application  Financial gain  Awards  Political reasons  Exploit of resources 7
    • 20/03/11Network solves security ?Firewalls … • Firewalls are always configured to allow web traffic -> HTTP(S) • Attacker appears to the web application as a normal user 8
    • 20/03/11Network solves security ?SSL secures the application… • Server-side SSL only guarantees confidentiality on transport level • Attacker also uses the SSL tunnel 9
    • 20/03/11 Secure Software Development LifeCycleSecurity Design Static Penetrationrequirements Review analysis testing (tools) Risk Risk-based analysis security tests Code Requirements Design Test plans Test Field and use cases results feedback Code Review 10
    • 20/03/11Application Risk Analysis Requirement and Architecture documentation Goal of the External In- & Output Assets Service Factors Channels Threat Analysis Identification Data Flow Identification Threat Trust levels Analysis of the threats analysis Risk Analysis Risk Risk Identification analysis Ranking of Mitigations document 11
    • 20/03/11How To• Security awareness and training program  Analysts  Security requirements -> Functional requirements  Use cases vs misUse cases  Architects & Developers  Data Flow Diagram analysis  Attack trees  STRIDE methodology• Development guidelines publication• Code Review  Automatic through tools  Manual by penetration testers 12
    • 20/03/11How To• Security Testing  Automatic through tools  Manual by penetration testers• Secure configuration• Technology  Web application firewall• Human Resources  Internal penetration testers (team)  Perform reviews & controls• Need of management support ! 13
    • 20/03/11Security Integration Processes• Clearly defined processes according to risks• 2 processes for the security analyses  Express (BPMN) Application-Security-Express-v0.2.igx Inception Elaboration Construction Transition Production Revue Revue de securité sur Revue de securité sur Revue Configuration testes Revue optionelle securité sur les reports danalyse les reports de test sécurité architecture feedback report de sécurité Security sécurité architecture, statique de code pénétration automatique Requirements V1 feedback report 1 jour Analist Requirements V1 req. V2 et 1/2 jour 1/2 jour Risc analysis 0,5 jour Risque 1,5 jour 1,5 jour Report de sécurité Verwerking CSM / CPL feedback Yes Verwerking Accepted feedback No Requirements V2 doc Analyste Requirements V1 doc RiSC V1 RiSC V2 TO&P Start SADV1 RiSC V1 Reports automatiques danalyse statiques de code RiSC V2 SADV2 Architecte Création du Création du TO&P SADV1 - critèr SADV2 - critèr es non es non fonctionnels Reports automatiques fonctionnels des testes de pénétration Developer la solution Developer Définir les Définir les Test de Requirements / Requirements / penetration critères non- critères non- automatique fonctionnels fonctionnels (2 à 3 jour) SIC iDeploy Deployment Client  Extended (BPMN) Security Analist Revue optionelle sécurité Requirements V1 0,5 jour Revue sécurité architecture Requirements V1 Risc analysis 1,5 jour feedback report Inception Revue securité sur architecture, req. V2 et Risque 1,5 jour feedback report Application-Security-Extended-v0.1.igx Elaboration Revue de securité sur les reports danalyse statique de code 1/2 jour Configuration testes de sécurité 1 jour Construction Revue de securité sur les reports de test pénétration automatique 1/2 jour Revue manuel sur le project >5 jour Transition Production Report de sécurité Verwerking CSM / CPL feedback Yes Verwerking Accepted feedback No Requirements V2 doc Requirements V1 doc Analyste RiSC V1 RiSC V2 TO&P Start SADV1 RiSC V1 Reports automatiques danalyse statiques de code RiSC V2 SADV2 Architecte Création du Création du TO&P SADV1 - critèr SADV2 - critèr es non es non Reports automatiques fonctionnels fonctionnels des testes de pénétration Developer la solution Developer Définir les Définir les Test de Requirements / Requirements / penetration critères non- critères non- automatique fonctionnels fonctionnels (2 à 3 jour) SIC iDeploy Deployment Client 14
    • 20/03/11Resources …• OWASP  Open Web Application Security Program• Books:  Software Security  Microsoft Secure Development Lifecycle  Enterprise Security Architecture 15
    • 20/03/11Questions ? Thanks you! www.smals.be 16