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.

1. 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

3. SECURING ENGINEERING

4. VULNERABILITIES IN SDLC PHASE
4

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

11. SSE-CMM (ISO/IEC 21827:2008)
11

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

16. SECURE SDLC (SDL)
16

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

21. THREAT MODELING

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

25. DIGRAMMATICALLY DOCUMENTS THREATS
25

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

30. SECURITY TESTING

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

34. STATIC ANALYSIS (CONT)
34

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

36. DYNAMIC ANALYSIS (RUN-TIME TEST)
36

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

38. LIVE DEMOS

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

41. 41
OPPORTUNITIES

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/