SlideShare a Scribd company logo

Security engineering

•Download as PPTX, PDF•
•
OWASP Indonesia Chapter
OWASP Indonesia Chapter

The document provides an overview of key security engineering activities that should be integrated into the software development lifecycle (SDLC). It discusses securing each phase of development through threat modeling, secure coding practices like code reviews, and security testing. The goal is to build security into applications from the start to help prevent vulnerabilities and deliver more robust products.

Related slideshows

Software security engineering
Software security engineeringSoftware security engineering
Software security engineering
 
Software security
Software securitySoftware security
Software security
 
Types of attacks
Types of attacksTypes of attacks
Types of attacks
 
1 of 45
SECURITY ENGINEERING
whoami Semi Yulianto BSc. (Accounting), M.IT (IT Security & Governance) Doctor in IT, Student at Graduate School of University of the East (Manila, Philippines) MCT, MCDBA, MCTS, MCITP, MCSA, MCSE, MCT, CCNP, CWNA, CEH, ECSA, CHFI, ECSP, EDRP, CND, CEI, SSCP, CISSP, CSSLP, CISA, CISM, CySA+, CASP, OSSA, CASE Java Co-Founder & CEO, Chief Hacking Officer (CHO) of PT. Systech Global Informasi (SGI Asia) // InfoSec Interim Consultant / Subject Matter Expert (SME) at PT. Trinusa Travelindo (Traveloka) // Information Security/Cyber Security Practitioner, Consultant, IS Auditor & Senior Technical Trainer // POJK & SEOJK Lead Auditor // US Military Approved Instructor (USFK – United States Force in Korea) // Author of Writing an Effective Penetration Testing Report: An Executive View (2014) course with 650+ enrolees (Pentest Magazine, Poland), also available in Amazon // Reviewer of Expert Metasploit Penetration Testing (2013) video course (Packt Publishing, UK) 2
SECURING ENGINEERING
VULNERABILITIES IN SDLC PHASE 4
VULNERABILITIES IN SDLC PHASE (CONT)  Addressing security in each phase of the SDLC is the most effective way to create highly secure applications.  Robust security-focused design principles followed by rigorous security-focused coding, testing, and deployment practices will lead to applications that can stand up to attacks.  This will result in lower ownership costs for both, the end user and the application vendor. 5
SECURING ENGINEERING  Securing Engineering presents an overview of key security engineering activities that should be an integral part of your application development lifecycle.  Key objective is to include specific security- related activities in your current software engineering processes. 6
SECURING ENGINEERING ACTIVITIES  Identifying security objectives.  Applying secure design guidelines, patterns and principles.  Creating threat models.  Conducting architecture and design reviews for security.  Performing regular code reviews for security. 7
SECURING ENGINEERING ACTIVITIES (CONT)  Testing for security.  Conducting development reviews to ensure secure configuration. 8
“ Security Engineering is a specialized field of software engineering that focuses on the security aspects in the design of systems that need to be able to deal robustly with possible sources of disruption (e.g. malicious acts). 9
THE BIG PICTURE Both Securing Engineering and Security Engineering focuses on the security aspects in software or systems development with the main objective IS to deliver robust products. 10
SSE-CMM (ISO/IEC 21827:2008) 11
SSE-CMM (CONT)  SSE-CMM (ISO/IEC 21827:2008) describes the essential characteristics of an organization's security engineering process that must exist to ensure good security engineering.  ISO/IEC 21827:2008 does not prescribe a particular process or sequence, but captures practices generally observed in industry. 12
SSE-CMM COVERAGE AREAS  the entire life cycle, including development, operation, maintenance and decommissioning activities;  the whole organization, including management, organizational and engineering activities; 13
SSE-CMM COVERAGE AREAS (CONT)  concurrent interactions with other disciplines, such as system, software, hardware, human factors and test engineering; system management, operation and maintenance;  interactions with other organizations, including acquisition, system management, certification, accreditation and evaluation. 14
LIFECYCLE INTEGRATION 15 CORE SECURITY Planning Requirements and Analysis Functional Requirements Non-Functional Requirements Technology Requirements Security Design Guidelines Threat Modeling Security Architecture and Design Review Development Unit Tests Code Review Daily Builds Security Code Review Testing Integration Testing System Testing Security Testing Deployment Deployment Review Security Deployment Review Maintenance
SECURE SDLC (SDL) 16
SECURITY ACTIVITIES 1. Security Objectives 2. Security Design Guidelines 3. Threat Modeling 4. Security Architecture and Design Review 5. Security Code Review 6. Security Testing 7. Security Deployment Review 17
SECURITY OBJECTIVES  Tangible Assets to Protect  User Accounts and Passwords  Confidential Information (e.g. CHD)  Sensitive Intellectual Property (IP)  Intangible Assets to Protect  Corporate Value  Company’s Reputation 18
SECURITY OBJECTIVES (CONT)  Compliance Requirements  Corporate Security Policies  Security Legislation  Privacy Legislation  Standards (e.g. PCI DSS, ISO 27001)  Quality of Service Requirements  Availability  Performance 19
TOP WEB APPLICATION SECURITY ISSUES 20
THREAT MODELING
“ Threat Modeling is the process of discovering potential security vulnerabilities in a design and eliminating those weaknesses or vulnerabilities before writing any code, fits best during the stage of planning and designing a new feature. The main objective is to create more secure software. 22
OWASP THREAT MODELING 23 DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5
THREAT MODELING ACTIVITIES 24 1. Identify Security Objectives 2. Application Overview 3. Decompose Application 4. Identify Threats 5. Identify Vulnerabilities
DIGRAMMATICALLY DOCUMENTS THREATS 25
COMMON WAYS TO RANK THE THREATS 26 1. Delphi Ranking 2. Average Ranking 3. Probability x Impact (P x I) Ranking
AVERAGE RANKING 27 THREAT D R E A DI AVERAGE RANK (D+R+E+A+DI)/5 SQL Injection 3 3 2 3 2 2.6 (High) Cross Site Scripting (XSS) 3 3 3 3 3 3.0 (High) Cookie Replay 3 2 2 1 2 2.0 (Medium) Session Hijacking 2 2 2 1 3 2.0 (Medium) Cross Site Request Forgery (CSRF) 3 1 1 1 1 1.4 (Medium) Verbose Exception 2 1 2 3 1 1.8 (Medium) Brute Forcing 2 1 1 3 2 1.8 (Medium) Eavesdropping 2 1 2 3 2 2.0 (Medium) Insecure Backup 1 1 2 1 2 1.4 (Medium) Audit Log Deletion 1 0 0 1 3 1.0 (Low) Output Caching 3 3 2 3 3 2.8 (High) Website Defacement 3 2 1 3 2 2.2 (High) Logic Flaws 1 1 1 2 1 1.2 (Low)
P x I RANKING 28 PROBABILITY OF OCCURRENCE (P) BUSINESS IMPACT (I) P I RISK THREAT R E DI D A (R+E+DI) (D+A) P X I SQL Injection 3 2 2 3 3 7 6 42 Cross Site Scripting (XSS) 3 3 3 3 3 9 6 54 Cookie Replay 2 2 2 3 1 6 4 24 Session Hijacking 2 2 3 2 1 7 3 21 Cross Site Request Forgery (CSRF) 1 1 1 3 1 3 4 12 Verbose Exception 1 2 1 2 3 4 5 20 Brute Forcing 1 1 2 2 3 4 5 20 Eavesdropping 1 2 2 2 3 5 5 25 Insecure Backup 1 2 2 1 1 5 2 10 Audit Log Deletion 0 0 3 1 1 3 2 06 Output Caching 3 2 3 3 3 8 6 48 Website Defacement 2 1 2 3 3 3 6 30 Logic Flaws 1 1 1 2 2 3 3 06
CONTROLS IDENTIFICATION 29 THREAT P X I CONTROLS Cross Site Scripting (XSS) 54 Encode output; Validate request; Validate input; Disallow script tags; Disable active scripting Output Caching 48 Don’t allow cache credentials; Complete mediation SQL Injection 42 Use parameterized queries; Validate input; Don’t allow dynamic construction of SQL Website Defacement 30 Load balancing and DR; Disallow URL redirection Eavesdropping 25 Data encryption; Sniffers detection; Disallow rogue systems Cookie Replay 24 Cookieless authentication; Encrypt cookies to avoid tampering Session Hijacking 21 Use random and non-sequential Session identifiers; Abandon session explicitly; Auto Log off on browser shutdown Verbose Exception 20 Use non-verbose error message; Trap, record, and handle errors; Fail secure Brute Forcing 20 Don’t allow weak passwords; Balance psychological acceptability with strong passwords Cross Site Request Forgery (CSRF) 12 Use unique session token; Use referrer origin checks; Complete mediation Insecure Backup 10 Data encryption; SSL (transport) or IPSec (network) in-transit protection; ACLs Audit Log Deletion 06 Don’t allow direct access to the database; Implement Access Triple security model; Separation of privilege Logic Flaws 06 Design reviews
SECURITY TESTING
TESTING TYPES  Static Analysis (Secure Code Review)  Coding Implementation Phase  Dynamic Analysis (Run-time Test)  Testing Phase 31
“ Static Analysis or Secure Code Review also known as SAST is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. 32
STATIC ANALYSIS (SECURE CODE REVIEW) 33
STATIC ANALYSIS (CONT) 34
“ Dynamic Analysis or Run-time Test also known as DAST is a technology, which is able to find visible vulnerabilities by feeding a URL into an automated scanner. Highly scalable, easily integrated and quick, drawbacks lie in the need for expert configuration and the high possibility of false positives and negatives. 35
DYNAMIC ANALYSIS (RUN-TIME TEST) 36
SECURITY ACTIVITIES (SURVEY) 37 0 5 10 15 20 25 30 Source Code Protection Fuzzing Threat Modeling Security Requirements Template Static Analysis Dynamic Analysis Security Enriched Code Libraries Automated Penetration Testing Training Security Code Review Manual Penetration Testing Final Security Review/Audit Other
LIVE DEMOS
CASE STUDY - HACME BANK V2.0 Background:  Hacme Bank v2.0 application simulates a real- world web services-enabled online banking application, which was built with a number of known and common vulnerabilities.  It allows users to attempt real exploits against a web application and thus learn the specifics of the issue and how best to fix it. 39
CASE STUDY - HACME BANK (CONT) Testing Types:  Manual Exploration/Testing  Dynamic Analysis (Run-time Test)  Static Analysis (Secure Code Review) 40
41 OPPORTUNITIES
CAREERS IN SOFTWARE SECURITY  Application Security Engineer  Security Architect  Security Analyst  Information Security Specialist  IT Security Engineer  Software QA 42  Test Engineer  Penetration Tester  IT Security Auditor  Source Code Auditor  DevOps Engineer  IT Security Consultant
SECURE CODING/SDLC TRAINING  EC-COUNCIL Certified Secure Programmer (ECSP) Java & .NET  EC-COUNCIL Certified Application Security Engineer (CASE) Java & .NET  ISC2 Certified Secure Software Lifecycle Professional (CSSLP)  ISC2 Certified Information Systems Security Professional (CISSP) 43
PROJECTS  Secure Coding Best Practices (Bahasa Indonesia Version) - Draft Version 0.1  Secure Coding/SDLC Awareness Training for Developers and InfoSec Professionals  Applications Threat and Vulnerability Database with Risk Ranking (Web and Mobile) 44
45 THANKS! Any questions? You can find me at: semi.yulianto2009@gmail.com +62 858 1325 6600 https://www.linkedin.com/in/semiyulianto/

More Related Content

Security engineering

  • 2. whoami Semi Yulianto BSc. (Accounting), M.IT (IT Security & Governance) Doctor in IT, Student at Graduate School of University of the East (Manila, Philippines) MCT, MCDBA, MCTS, MCITP, MCSA, MCSE, MCT, CCNP, CWNA, CEH, ECSA, CHFI, ECSP, EDRP, CND, CEI, SSCP, CISSP, CSSLP, CISA, CISM, CySA+, CASP, OSSA, CASE Java Co-Founder & CEO, Chief Hacking Officer (CHO) of PT. Systech Global Informasi (SGI Asia) // InfoSec Interim Consultant / Subject Matter Expert (SME) at PT. Trinusa Travelindo (Traveloka) // Information Security/Cyber Security Practitioner, Consultant, IS Auditor & Senior Technical Trainer // POJK & SEOJK Lead Auditor // US Military Approved Instructor (USFK – United States Force in Korea) // Author of Writing an Effective Penetration Testing Report: An Executive View (2014) course with 650+ enrolees (Pentest Magazine, Poland), also available in Amazon // Reviewer of Expert Metasploit Penetration Testing (2013) video course (Packt Publishing, UK) 2
  • 5. VULNERABILITIES IN SDLC PHASE (CONT)  Addressing security in each phase of the SDLC is the most effective way to create highly secure applications.  Robust security-focused design principles followed by rigorous security-focused coding, testing, and deployment practices will lead to applications that can stand up to attacks.  This will result in lower ownership costs for both, the end user and the application vendor. 5
  • 6. SECURING ENGINEERING  Securing Engineering presents an overview of key security engineering activities that should be an integral part of your application development lifecycle.  Key objective is to include specific security- related activities in your current software engineering processes. 6
  • 7. SECURING ENGINEERING ACTIVITIES  Identifying security objectives.  Applying secure design guidelines, patterns and principles.  Creating threat models.  Conducting architecture and design reviews for security.  Performing regular code reviews for security. 7
  • 8. SECURING ENGINEERING ACTIVITIES (CONT)  Testing for security.  Conducting development reviews to ensure secure configuration. 8
  • 9. “ Security Engineering is a specialized field of software engineering that focuses on the security aspects in the design of systems that need to be able to deal robustly with possible sources of disruption (e.g. malicious acts). 9
  • 10. THE BIG PICTURE Both Securing Engineering and Security Engineering focuses on the security aspects in software or systems development with the main objective IS to deliver robust products. 10
  • 12. SSE-CMM (CONT)  SSE-CMM (ISO/IEC 21827:2008) describes the essential characteristics of an organization's security engineering process that must exist to ensure good security engineering.  ISO/IEC 21827:2008 does not prescribe a particular process or sequence, but captures practices generally observed in industry. 12
  • 13. SSE-CMM COVERAGE AREAS  the entire life cycle, including development, operation, maintenance and decommissioning activities;  the whole organization, including management, organizational and engineering activities; 13
  • 14. SSE-CMM COVERAGE AREAS (CONT)  concurrent interactions with other disciplines, such as system, software, hardware, human factors and test engineering; system management, operation and maintenance;  interactions with other organizations, including acquisition, system management, certification, accreditation and evaluation. 14
  • 15. LIFECYCLE INTEGRATION 15 CORE SECURITY Planning Requirements and Analysis Functional Requirements Non-Functional Requirements Technology Requirements Security Design Guidelines Threat Modeling Security Architecture and Design Review Development Unit Tests Code Review Daily Builds Security Code Review Testing Integration Testing System Testing Security Testing Deployment Deployment Review Security Deployment Review Maintenance
  • 17. SECURITY ACTIVITIES 1. Security Objectives 2. Security Design Guidelines 3. Threat Modeling 4. Security Architecture and Design Review 5. Security Code Review 6. Security Testing 7. Security Deployment Review 17
  • 18. SECURITY OBJECTIVES  Tangible Assets to Protect  User Accounts and Passwords  Confidential Information (e.g. CHD)  Sensitive Intellectual Property (IP)  Intangible Assets to Protect  Corporate Value  Company’s Reputation 18
  • 19. SECURITY OBJECTIVES (CONT)  Compliance Requirements  Corporate Security Policies  Security Legislation  Privacy Legislation  Standards (e.g. PCI DSS, ISO 27001)  Quality of Service Requirements  Availability  Performance 19
  • 20. TOP WEB APPLICATION SECURITY ISSUES 20
  • 22. “ Threat Modeling is the process of discovering potential security vulnerabilities in a design and eliminating those weaknesses or vulnerabilities before writing any code, fits best during the stage of planning and designing a new feature. The main objective is to create more secure software. 22
  • 23. OWASP THREAT MODELING 23 DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5
  • 24. THREAT MODELING ACTIVITIES 24 1. Identify Security Objectives 2. Application Overview 3. Decompose Application 4. Identify Threats 5. Identify Vulnerabilities
  • 26. COMMON WAYS TO RANK THE THREATS 26 1. Delphi Ranking 2. Average Ranking 3. Probability x Impact (P x I) Ranking
  • 27. AVERAGE RANKING 27 THREAT D R E A DI AVERAGE RANK (D+R+E+A+DI)/5 SQL Injection 3 3 2 3 2 2.6 (High) Cross Site Scripting (XSS) 3 3 3 3 3 3.0 (High) Cookie Replay 3 2 2 1 2 2.0 (Medium) Session Hijacking 2 2 2 1 3 2.0 (Medium) Cross Site Request Forgery (CSRF) 3 1 1 1 1 1.4 (Medium) Verbose Exception 2 1 2 3 1 1.8 (Medium) Brute Forcing 2 1 1 3 2 1.8 (Medium) Eavesdropping 2 1 2 3 2 2.0 (Medium) Insecure Backup 1 1 2 1 2 1.4 (Medium) Audit Log Deletion 1 0 0 1 3 1.0 (Low) Output Caching 3 3 2 3 3 2.8 (High) Website Defacement 3 2 1 3 2 2.2 (High) Logic Flaws 1 1 1 2 1 1.2 (Low)
  • 28. P x I RANKING 28 PROBABILITY OF OCCURRENCE (P) BUSINESS IMPACT (I) P I RISK THREAT R E DI D A (R+E+DI) (D+A) P X I SQL Injection 3 2 2 3 3 7 6 42 Cross Site Scripting (XSS) 3 3 3 3 3 9 6 54 Cookie Replay 2 2 2 3 1 6 4 24 Session Hijacking 2 2 3 2 1 7 3 21 Cross Site Request Forgery (CSRF) 1 1 1 3 1 3 4 12 Verbose Exception 1 2 1 2 3 4 5 20 Brute Forcing 1 1 2 2 3 4 5 20 Eavesdropping 1 2 2 2 3 5 5 25 Insecure Backup 1 2 2 1 1 5 2 10 Audit Log Deletion 0 0 3 1 1 3 2 06 Output Caching 3 2 3 3 3 8 6 48 Website Defacement 2 1 2 3 3 3 6 30 Logic Flaws 1 1 1 2 2 3 3 06
  • 29. CONTROLS IDENTIFICATION 29 THREAT P X I CONTROLS Cross Site Scripting (XSS) 54 Encode output; Validate request; Validate input; Disallow script tags; Disable active scripting Output Caching 48 Don’t allow cache credentials; Complete mediation SQL Injection 42 Use parameterized queries; Validate input; Don’t allow dynamic construction of SQL Website Defacement 30 Load balancing and DR; Disallow URL redirection Eavesdropping 25 Data encryption; Sniffers detection; Disallow rogue systems Cookie Replay 24 Cookieless authentication; Encrypt cookies to avoid tampering Session Hijacking 21 Use random and non-sequential Session identifiers; Abandon session explicitly; Auto Log off on browser shutdown Verbose Exception 20 Use non-verbose error message; Trap, record, and handle errors; Fail secure Brute Forcing 20 Don’t allow weak passwords; Balance psychological acceptability with strong passwords Cross Site Request Forgery (CSRF) 12 Use unique session token; Use referrer origin checks; Complete mediation Insecure Backup 10 Data encryption; SSL (transport) or IPSec (network) in-transit protection; ACLs Audit Log Deletion 06 Don’t allow direct access to the database; Implement Access Triple security model; Separation of privilege Logic Flaws 06 Design reviews
  • 31. TESTING TYPES  Static Analysis (Secure Code Review)  Coding Implementation Phase  Dynamic Analysis (Run-time Test)  Testing Phase 31
  • 32. “ Static Analysis or Secure Code Review also known as SAST is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. 32
  • 33. STATIC ANALYSIS (SECURE CODE REVIEW) 33
  • 35. “ Dynamic Analysis or Run-time Test also known as DAST is a technology, which is able to find visible vulnerabilities by feeding a URL into an automated scanner. Highly scalable, easily integrated and quick, drawbacks lie in the need for expert configuration and the high possibility of false positives and negatives. 35
  • 37. SECURITY ACTIVITIES (SURVEY) 37 0 5 10 15 20 25 30 Source Code Protection Fuzzing Threat Modeling Security Requirements Template Static Analysis Dynamic Analysis Security Enriched Code Libraries Automated Penetration Testing Training Security Code Review Manual Penetration Testing Final Security Review/Audit Other
  • 39. CASE STUDY - HACME BANK V2.0 Background:  Hacme Bank v2.0 application simulates a real- world web services-enabled online banking application, which was built with a number of known and common vulnerabilities.  It allows users to attempt real exploits against a web application and thus learn the specifics of the issue and how best to fix it. 39
  • 40. CASE STUDY - HACME BANK (CONT) Testing Types:  Manual Exploration/Testing  Dynamic Analysis (Run-time Test)  Static Analysis (Secure Code Review) 40
  • 42. CAREERS IN SOFTWARE SECURITY  Application Security Engineer  Security Architect  Security Analyst  Information Security Specialist  IT Security Engineer  Software QA 42  Test Engineer  Penetration Tester  IT Security Auditor  Source Code Auditor  DevOps Engineer  IT Security Consultant
  • 43. SECURE CODING/SDLC TRAINING  EC-COUNCIL Certified Secure Programmer (ECSP) Java & .NET  EC-COUNCIL Certified Application Security Engineer (CASE) Java & .NET  ISC2 Certified Secure Software Lifecycle Professional (CSSLP)  ISC2 Certified Information Systems Security Professional (CISSP) 43
  • 44. PROJECTS  Secure Coding Best Practices (Bahasa Indonesia Version) - Draft Version 0.1  Secure Coding/SDLC Awareness Training for Developers and InfoSec Professionals  Applications Threat and Vulnerability Database with Risk Ranking (Web and Mobile) 44
  • 45. 45 THANKS! Any questions? You can find me at: semi.yulianto2009@gmail.com +62 858 1325 6600 https://www.linkedin.com/in/semiyulianto/