SlideShare a Scribd company logo
1 of 26
Download to read offline
Christopher M. Frenz
   According to a
    September 2009 SANS
    report:
    ◦ 60% of all internet attacks
      target Web applications
    ◦ SQL Injection and XSS
      constitute 80% of all
      recently discovered
      vulnerabilities
    ◦ Application vulnerabilities
      now exceed OS                 Image Source: http://www.sans.org/top-
      vulnerabilities               cyber-security-risks/trends.php
   Injection
   Cross Site Scripting
   Broken Authentication and Session Management
   Insecure Direct Object References
   Cross Site Request Forgery
   Security Misconfiguration
   Insecure Cryptographic Storage
   Failure to Restrict URL Access
   Insufficient Transport Layer Protection
   Unwanted Redirects and Forwarding
   More developers need to be made aware of
    the need for secure software development as
    well as the practices associated with secure
    software development
    ◦ Education is key
   Security needs to be part of the mindset of
    any software development project from day 1
    ◦ Security CANNOT be an afterthought
    ◦ Security CANNOT be effectively added on later (e.g.
      firewalls)
   Requirements
   Design
   Implementation
   Testing
   Release/Maintain
   A requirements analysis is used to determine
    the needs and goals that a software project
    must meet
    ◦ Security NEEDS to be a requirement
   Threat Modeling and Risk Assessment are
    often used to help identify and evaluate
    security requirements
    ◦ Examples include
      STRIDE and DREAD
      OCTAVE
   A threat modeling methodology
    ◦   Spoofing
    ◦   Tampering
    ◦   Repudiation
    ◦   Information disclosure
    ◦   Denial of Service
    ◦   Elevation of privilege
   Makes programmers think like an attacker in
    order to identify potential ways in which their
    application could be abused
   A risk assessment methodology used to rank
    threats according to
    ◦   Damage potential
    ◦   Reproducibility
    ◦   Exploitability
    ◦   Affected Users
    ◦   Discoverability
   Each threat is ranked in each category on a
    scale of 1 to 3, with 1 being a threat with
    minimal potential impact and 3 being a
    serious threat
Threat     D        R         E          A         D         Average
XSS        3        3         2          3         3         2.6
Log        1        1         1          1         1         1
Deletion



 This methodology allows you to identify which threats pose the
 biggest risk to your application
   The design phase of software development
    lays out the application architecture and
    creates the framework upon which the
    implementation of the software will be based
   The design phase must specify what security
    controls will be implemented in the
    application and how those security controls
    are to be implemented
   The design must be sure to meet all
    established security requirements
   Input Validation
    ◦ Whitelisting – matches a US phone #
       (s?(?d{3})?[-s.]?d{3}[-.]d{4})
    ◦ Blacklisting – matches html tags
       ((%3C)|<).*?((%3E)|>)
   Escaping
    ◦ Converting < to &lt to render content contained in
      <script></script> tags non-executable
   Error Handling
    ◦ Don’t want your application to crash if something
      unexpected or unaccounted for happens
   Encryption
    ◦ Don’t want someone sniffing your data or seeing
      something they were never meant to see
   Authentication
    ◦ Need to ensure that only valid users gain access
   Session Management
    ◦ Make sure that no one can MITM your sessions or
      reinstitute a closed session
   Thread Management
    ◦ Don’t allow for the potential for race conditions or
      deadlocks
   And many more …
   It is important to take time to review your
    own design and have others review your
    design to make sure there are no design
    weaknesses.
   It is much easier (and cheaper) to fix a
    problem at an early stage of the SDLC than at
    a later stage
   Poor design contributes to some of the worst
    application security problems
   The implementation phase deals with the
    actual writing of code
   Before any code is written secure coding
    standards should be in place and developers
    educated in the importance and requirements
    of these standards
   Standards help to prevent the introduction of
    potential vulnerabilities such as buffer
    overflows
   Occur when code is written that allows more
    data to be passed into a buffer than the
    buffer was designed to contain
   Excess data passed into the buffer can
    overwrite data in memory and allow an
    attacker to inject his own instructions
    (typically shellcode)
   Shellcode provides machine instructions for
    opening up a shell (terminal) on a
    compromised machine
   xebx1fx5ex89x76x08x31xc0x88x
    46x07x89x46x0cxb0x0bx89xf3x8
    dx4ex08x8dx56x0cxcdx80x31xdb
    x89xd8x40xcdx80xe8xdcxffxffxff
    /bin/sh
void function (char *str) {
   char buffer[16];
   strcpy (buffer, str);
}
int main () {
  char *str = "I am greater than 16 bytes"; // length of str = 27 bytes
  function (str);
}
   A static code analyzer that can be used to
    detect potential security bugs in code such as
    buffer overflows
   Peer code review can also be beneficial since
    it can help to pick up errors that static code
    analyzers will not be able to identify such as
    an improper implementation of the design
    specifications
   While many developers are resistant to the
    idea of code reviews they can be a valuable
    security and educational tool
    ◦ Developers are often too close to their own code to
      see some flaws
   Testing normally entails verification that the
    application functions properly when
    presented with a series of use cases
   Security testing needs to go beyond use cases
    and also present the application with “abuse”
    cases designed to test security controls such
    as input validation, error handling, etc
   Fuzzing is an automated process of providing
    invalid and random inputs into an application
    and monitoring the application for crashes
   It can help to identify inputs that the
    application cannot properly handle and that
    hence could be used as potential attack
    vectors
   Examples
    ◦ PeachFuzzer
    ◦ JBroFuzz
   Some organizations will also elect to perform
    penetration testing against their application
   Pen testing involves an EXPERIENCED attacker
    targeting your application and can often lead
    to the discovery of vulnerabilities that
    automated testing will not find
   Application pen testing is different than
    network security pen testing
    ◦ Make sure your pen tester has application security
      experience
   While it is reasonable for pen testers to make
    use of vulnerability scanners a vulnerability
    scan is not a pen test
    ◦ Passing a Nessus scan does not, in and of itself,
      mean your application is secure
   Eventually it will come time to release and
    distribute your application
   No matter how carefully you adhered to
    secure SDLC practices your code WILL have
    bugs in it
   Responsible organizations should have plans
    in place to deal with the identification,
    verification, patching of bugs, as well as the
    distribution of updates, prior to the product
    being released
   Software security is a much needed skill set
    amongst software developers
   Improvements in application security will be
    highly beneficial to improving the security of
    information systems
   Security needs to be a continuous process
    that begins with the onset of the software
    project inception and persists throughout the
    lifetime of the project
   OWASP -
    https://www.owasp.org/index.php/Main_Page
   Building Security In - https://buildsecurityin.us-
    cert.gov/bsi/home.html
   McGraw, G. (2006) Software Security: Building
    Security In, Addison Wesley
   Howard, M. & Lipner, S. (2006) The Security
    Development Lifecycle, Microsoft Press

More Related Content

What's hot

Threat Modeling And Analysis
Threat Modeling And AnalysisThreat Modeling And Analysis
Threat Modeling And AnalysisLalit Kale
 
Threat Modeling 101
Threat Modeling 101Threat Modeling 101
Threat Modeling 101Vlad Styran
 
Attack modeling vs threat modelling
Attack modeling vs threat modellingAttack modeling vs threat modelling
Attack modeling vs threat modellingInvisibits
 
STRIDE And DREAD
STRIDE And DREADSTRIDE And DREAD
STRIDE And DREADchuckbt
 
Threat Modeling: Best Practices
Threat Modeling: Best PracticesThreat Modeling: Best Practices
Threat Modeling: Best PracticesSource Conference
 
Microsoft threat modeling tool 2016
Microsoft threat modeling tool 2016Microsoft threat modeling tool 2016
Microsoft threat modeling tool 2016Rihab Chebbah
 
Security Compliance Web Application Risk Management
Security Compliance Web Application Risk ManagementSecurity Compliance Web Application Risk Management
Security Compliance Web Application Risk ManagementMarco Morana
 
Threat modelling(system + enterprise)
Threat modelling(system + enterprise)Threat modelling(system + enterprise)
Threat modelling(system + enterprise)abhimanyubhogwan
 
An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)
An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)
An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)FFRI, Inc.
 
DevSecCon Talk: An experiment in agile Threat Modelling
DevSecCon Talk: An experiment in agile Threat ModellingDevSecCon Talk: An experiment in agile Threat Modelling
DevSecCon Talk: An experiment in agile Threat ModellingzeroXten
 
Microsoft threat modeling tool 2016
Microsoft threat modeling tool 2016Microsoft threat modeling tool 2016
Microsoft threat modeling tool 2016Kannan Ganapathy
 
Threat Simulation and Modeling Training
Threat Simulation and Modeling TrainingThreat Simulation and Modeling Training
Threat Simulation and Modeling TrainingBryan Len
 
Application Threat Modeling
Application Threat ModelingApplication Threat Modeling
Application Threat ModelingPriyanka Aash
 
Developing a Threat Modeling Mindset
Developing a Threat Modeling MindsetDeveloping a Threat Modeling Mindset
Developing a Threat Modeling MindsetRobert Hurlbut
 
A Brief Introduction to Penetration Testing
A Brief Introduction to Penetration TestingA Brief Introduction to Penetration Testing
A Brief Introduction to Penetration TestingEC-Council
 

What's hot (20)

Threat Modeling And Analysis
Threat Modeling And AnalysisThreat Modeling And Analysis
Threat Modeling And Analysis
 
Null bachav
Null bachavNull bachav
Null bachav
 
Threat Modeling 101
Threat Modeling 101Threat Modeling 101
Threat Modeling 101
 
Attack modeling vs threat modelling
Attack modeling vs threat modellingAttack modeling vs threat modelling
Attack modeling vs threat modelling
 
STRIDE And DREAD
STRIDE And DREADSTRIDE And DREAD
STRIDE And DREAD
 
Threat Modeling: Best Practices
Threat Modeling: Best PracticesThreat Modeling: Best Practices
Threat Modeling: Best Practices
 
Microsoft threat modeling tool 2016
Microsoft threat modeling tool 2016Microsoft threat modeling tool 2016
Microsoft threat modeling tool 2016
 
Security Compliance Web Application Risk Management
Security Compliance Web Application Risk ManagementSecurity Compliance Web Application Risk Management
Security Compliance Web Application Risk Management
 
Application Threat Modeling
Application Threat ModelingApplication Threat Modeling
Application Threat Modeling
 
Security overview 2
Security overview 2Security overview 2
Security overview 2
 
Threat modelling(system + enterprise)
Threat modelling(system + enterprise)Threat modelling(system + enterprise)
Threat modelling(system + enterprise)
 
An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)
An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)
An Example of use the Threat Modeling Tool (FFRI Monthly Research Nov 2016)
 
DevSecCon Talk: An experiment in agile Threat Modelling
DevSecCon Talk: An experiment in agile Threat ModellingDevSecCon Talk: An experiment in agile Threat Modelling
DevSecCon Talk: An experiment in agile Threat Modelling
 
Microsoft threat modeling tool 2016
Microsoft threat modeling tool 2016Microsoft threat modeling tool 2016
Microsoft threat modeling tool 2016
 
Threat Simulation and Modeling Training
Threat Simulation and Modeling TrainingThreat Simulation and Modeling Training
Threat Simulation and Modeling Training
 
Application Threat Modeling
Application Threat ModelingApplication Threat Modeling
Application Threat Modeling
 
Developing a Threat Modeling Mindset
Developing a Threat Modeling MindsetDeveloping a Threat Modeling Mindset
Developing a Threat Modeling Mindset
 
A Brief Introduction to Penetration Testing
A Brief Introduction to Penetration TestingA Brief Introduction to Penetration Testing
A Brief Introduction to Penetration Testing
 
Introduction to threat_modeling
Introduction to threat_modelingIntroduction to threat_modeling
Introduction to threat_modeling
 
Secure coding-guidelines
Secure coding-guidelinesSecure coding-guidelines
Secure coding-guidelines
 

Viewers also liked

The Principles of Secure Development - Epicenter Dublin
The Principles of Secure Development - Epicenter DublinThe Principles of Secure Development - Epicenter Dublin
The Principles of Secure Development - Epicenter DublinSecurity Ninja
 
Agile Secure Development
Agile Secure DevelopmentAgile Secure Development
Agile Secure DevelopmentBosnia Agile
 
OWASP Secure Coding
OWASP Secure CodingOWASP Secure Coding
OWASP Secure Codingbilcorry
 
Secure Software Development Life Cycle
Secure Software Development Life CycleSecure Software Development Life Cycle
Secure Software Development Life CycleMaurice Dawson
 
Secure coding practices
Secure coding practicesSecure coding practices
Secure coding practicesScott Hurrey
 
The Outcome Economy
The Outcome EconomyThe Outcome Economy
The Outcome EconomyHelge Tennø
 

Viewers also liked (9)

The Principles of Secure Development - Epicenter Dublin
The Principles of Secure Development - Epicenter DublinThe Principles of Secure Development - Epicenter Dublin
The Principles of Secure Development - Epicenter Dublin
 
Secure Software Development Adoption Strategy
Secure Software Development Adoption StrategySecure Software Development Adoption Strategy
Secure Software Development Adoption Strategy
 
Agile Secure Development
Agile Secure DevelopmentAgile Secure Development
Agile Secure Development
 
OWASP Secure Coding
OWASP Secure CodingOWASP Secure Coding
OWASP Secure Coding
 
Secure Software Development Life Cycle
Secure Software Development Life CycleSecure Software Development Life Cycle
Secure Software Development Life Cycle
 
Secure coding practices
Secure coding practicesSecure coding practices
Secure coding practices
 
Agile and Secure SDLC
Agile and Secure SDLCAgile and Secure SDLC
Agile and Secure SDLC
 
Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
 
The Outcome Economy
The Outcome EconomyThe Outcome Economy
The Outcome Economy
 

Similar to An Introduction to Secure Application Development

Security engineering 101 when good design & security work together
Security engineering 101  when good design & security work togetherSecurity engineering 101  when good design & security work together
Security engineering 101 when good design & security work togetherWendy Knox Everette
 
Software Security Testing
Software Security TestingSoftware Security Testing
Software Security Testingankitmehta21
 
Fendley how secure is your e learning
Fendley how secure is your e learningFendley how secure is your e learning
Fendley how secure is your e learningBryan Fendley
 
Security Best Practices
Security Best PracticesSecurity Best Practices
Security Best PracticesClint Edmonson
 
chap-1 : Vulnerabilities in Information Systems
chap-1 : Vulnerabilities in Information Systemschap-1 : Vulnerabilities in Information Systems
chap-1 : Vulnerabilities in Information SystemsKashfUlHuda1
 
Application Security Testing for Software Engineers: An approach to build sof...
Application Security Testing for Software Engineers: An approach to build sof...Application Security Testing for Software Engineers: An approach to build sof...
Application Security Testing for Software Engineers: An approach to build sof...Michael Hidalgo
 
Appsec2013 assurance tagging-robert martin
Appsec2013 assurance tagging-robert martinAppsec2013 assurance tagging-robert martin
Appsec2013 assurance tagging-robert martindrewz lin
 
OWASP Secure Coding Quick Reference Guide
OWASP Secure Coding Quick Reference GuideOWASP Secure Coding Quick Reference Guide
OWASP Secure Coding Quick Reference GuideAryan G
 
Software Security Engineering
Software Security EngineeringSoftware Security Engineering
Software Security EngineeringMarco Morana
 
Building an AppSec Team Extended Cut
Building an AppSec Team Extended CutBuilding an AppSec Team Extended Cut
Building an AppSec Team Extended CutMike Spaulding
 
Mike Spaulding - Building an Application Security Program
Mike Spaulding - Building an Application Security ProgramMike Spaulding - Building an Application Security Program
Mike Spaulding - Building an Application Security Programcentralohioissa
 
Importance of Secure Coding with it’s Best Practices
Importance of Secure Coding with it’s Best PracticesImportance of Secure Coding with it’s Best Practices
Importance of Secure Coding with it’s Best PracticesElanusTechnologies
 
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare ☁
 
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare ☁
 
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare ☁
 
EISA Considerations for Web Application Security
EISA Considerations for Web Application SecurityEISA Considerations for Web Application Security
EISA Considerations for Web Application SecurityLarry Ball
 
For Business's Sake, Let's focus on AppSec
For Business's Sake, Let's focus on AppSecFor Business's Sake, Let's focus on AppSec
For Business's Sake, Let's focus on AppSecLalit Kale
 

Similar to An Introduction to Secure Application Development (20)

FALCON.pptx
FALCON.pptxFALCON.pptx
FALCON.pptx
 
Arved sandstrom - the rotwithin - atlseccon2011
Arved sandstrom - the rotwithin - atlseccon2011Arved sandstrom - the rotwithin - atlseccon2011
Arved sandstrom - the rotwithin - atlseccon2011
 
Security engineering 101 when good design & security work together
Security engineering 101  when good design & security work togetherSecurity engineering 101  when good design & security work together
Security engineering 101 when good design & security work together
 
Software Security Testing
Software Security TestingSoftware Security Testing
Software Security Testing
 
Fendley how secure is your e learning
Fendley how secure is your e learningFendley how secure is your e learning
Fendley how secure is your e learning
 
Security Best Practices
Security Best PracticesSecurity Best Practices
Security Best Practices
 
chap-1 : Vulnerabilities in Information Systems
chap-1 : Vulnerabilities in Information Systemschap-1 : Vulnerabilities in Information Systems
chap-1 : Vulnerabilities in Information Systems
 
Application Security Testing for Software Engineers: An approach to build sof...
Application Security Testing for Software Engineers: An approach to build sof...Application Security Testing for Software Engineers: An approach to build sof...
Application Security Testing for Software Engineers: An approach to build sof...
 
Appsec2013 assurance tagging-robert martin
Appsec2013 assurance tagging-robert martinAppsec2013 assurance tagging-robert martin
Appsec2013 assurance tagging-robert martin
 
OWASP Secure Coding Quick Reference Guide
OWASP Secure Coding Quick Reference GuideOWASP Secure Coding Quick Reference Guide
OWASP Secure Coding Quick Reference Guide
 
Software Security Engineering
Software Security EngineeringSoftware Security Engineering
Software Security Engineering
 
C01461422
C01461422C01461422
C01461422
 
Building an AppSec Team Extended Cut
Building an AppSec Team Extended CutBuilding an AppSec Team Extended Cut
Building an AppSec Team Extended Cut
 
Mike Spaulding - Building an Application Security Program
Mike Spaulding - Building an Application Security ProgramMike Spaulding - Building an Application Security Program
Mike Spaulding - Building an Application Security Program
 
Importance of Secure Coding with it’s Best Practices
Importance of Secure Coding with it’s Best PracticesImportance of Secure Coding with it’s Best Practices
Importance of Secure Coding with it’s Best Practices
 
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
 
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
 
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
Manoj Purandare - Application Security - Secure Code Assessment Program - Pre...
 
EISA Considerations for Web Application Security
EISA Considerations for Web Application SecurityEISA Considerations for Web Application Security
EISA Considerations for Web Application Security
 
For Business's Sake, Let's focus on AppSec
For Business's Sake, Let's focus on AppSecFor Business's Sake, Let's focus on AppSec
For Business's Sake, Let's focus on AppSec
 

An Introduction to Secure Application Development

  • 2. According to a September 2009 SANS report: ◦ 60% of all internet attacks target Web applications ◦ SQL Injection and XSS constitute 80% of all recently discovered vulnerabilities ◦ Application vulnerabilities now exceed OS Image Source: http://www.sans.org/top- vulnerabilities cyber-security-risks/trends.php
  • 3. Injection  Cross Site Scripting  Broken Authentication and Session Management  Insecure Direct Object References  Cross Site Request Forgery  Security Misconfiguration  Insecure Cryptographic Storage  Failure to Restrict URL Access  Insufficient Transport Layer Protection  Unwanted Redirects and Forwarding
  • 4. More developers need to be made aware of the need for secure software development as well as the practices associated with secure software development ◦ Education is key  Security needs to be part of the mindset of any software development project from day 1 ◦ Security CANNOT be an afterthought ◦ Security CANNOT be effectively added on later (e.g. firewalls)
  • 5. Requirements  Design  Implementation  Testing  Release/Maintain
  • 6. A requirements analysis is used to determine the needs and goals that a software project must meet ◦ Security NEEDS to be a requirement  Threat Modeling and Risk Assessment are often used to help identify and evaluate security requirements ◦ Examples include  STRIDE and DREAD  OCTAVE
  • 7. A threat modeling methodology ◦ Spoofing ◦ Tampering ◦ Repudiation ◦ Information disclosure ◦ Denial of Service ◦ Elevation of privilege  Makes programmers think like an attacker in order to identify potential ways in which their application could be abused
  • 8. A risk assessment methodology used to rank threats according to ◦ Damage potential ◦ Reproducibility ◦ Exploitability ◦ Affected Users ◦ Discoverability  Each threat is ranked in each category on a scale of 1 to 3, with 1 being a threat with minimal potential impact and 3 being a serious threat
  • 9. Threat D R E A D Average XSS 3 3 2 3 3 2.6 Log 1 1 1 1 1 1 Deletion This methodology allows you to identify which threats pose the biggest risk to your application
  • 10. The design phase of software development lays out the application architecture and creates the framework upon which the implementation of the software will be based  The design phase must specify what security controls will be implemented in the application and how those security controls are to be implemented  The design must be sure to meet all established security requirements
  • 11. Input Validation ◦ Whitelisting – matches a US phone #  (s?(?d{3})?[-s.]?d{3}[-.]d{4}) ◦ Blacklisting – matches html tags  ((%3C)|<).*?((%3E)|>)  Escaping ◦ Converting < to &lt to render content contained in <script></script> tags non-executable  Error Handling ◦ Don’t want your application to crash if something unexpected or unaccounted for happens  Encryption ◦ Don’t want someone sniffing your data or seeing something they were never meant to see
  • 12. Authentication ◦ Need to ensure that only valid users gain access  Session Management ◦ Make sure that no one can MITM your sessions or reinstitute a closed session  Thread Management ◦ Don’t allow for the potential for race conditions or deadlocks  And many more …
  • 13. It is important to take time to review your own design and have others review your design to make sure there are no design weaknesses.  It is much easier (and cheaper) to fix a problem at an early stage of the SDLC than at a later stage  Poor design contributes to some of the worst application security problems
  • 14. The implementation phase deals with the actual writing of code  Before any code is written secure coding standards should be in place and developers educated in the importance and requirements of these standards  Standards help to prevent the introduction of potential vulnerabilities such as buffer overflows
  • 15. Occur when code is written that allows more data to be passed into a buffer than the buffer was designed to contain  Excess data passed into the buffer can overwrite data in memory and allow an attacker to inject his own instructions (typically shellcode)
  • 16. Shellcode provides machine instructions for opening up a shell (terminal) on a compromised machine  xebx1fx5ex89x76x08x31xc0x88x 46x07x89x46x0cxb0x0bx89xf3x8 dx4ex08x8dx56x0cxcdx80x31xdb x89xd8x40xcdx80xe8xdcxffxffxff /bin/sh
  • 17. void function (char *str) { char buffer[16]; strcpy (buffer, str); } int main () { char *str = "I am greater than 16 bytes"; // length of str = 27 bytes function (str); }
  • 18. A static code analyzer that can be used to detect potential security bugs in code such as buffer overflows
  • 19. Peer code review can also be beneficial since it can help to pick up errors that static code analyzers will not be able to identify such as an improper implementation of the design specifications  While many developers are resistant to the idea of code reviews they can be a valuable security and educational tool ◦ Developers are often too close to their own code to see some flaws
  • 20. Testing normally entails verification that the application functions properly when presented with a series of use cases  Security testing needs to go beyond use cases and also present the application with “abuse” cases designed to test security controls such as input validation, error handling, etc
  • 21. Fuzzing is an automated process of providing invalid and random inputs into an application and monitoring the application for crashes  It can help to identify inputs that the application cannot properly handle and that hence could be used as potential attack vectors  Examples ◦ PeachFuzzer ◦ JBroFuzz
  • 22. Some organizations will also elect to perform penetration testing against their application  Pen testing involves an EXPERIENCED attacker targeting your application and can often lead to the discovery of vulnerabilities that automated testing will not find
  • 23. Application pen testing is different than network security pen testing ◦ Make sure your pen tester has application security experience  While it is reasonable for pen testers to make use of vulnerability scanners a vulnerability scan is not a pen test ◦ Passing a Nessus scan does not, in and of itself, mean your application is secure
  • 24. Eventually it will come time to release and distribute your application  No matter how carefully you adhered to secure SDLC practices your code WILL have bugs in it  Responsible organizations should have plans in place to deal with the identification, verification, patching of bugs, as well as the distribution of updates, prior to the product being released
  • 25. Software security is a much needed skill set amongst software developers  Improvements in application security will be highly beneficial to improving the security of information systems  Security needs to be a continuous process that begins with the onset of the software project inception and persists throughout the lifetime of the project
  • 26. OWASP - https://www.owasp.org/index.php/Main_Page  Building Security In - https://buildsecurityin.us- cert.gov/bsi/home.html  McGraw, G. (2006) Software Security: Building Security In, Addison Wesley  Howard, M. & Lipner, S. (2006) The Security Development Lifecycle, Microsoft Press