Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

For Business's Sake, Let's focus on AppSec

Slide-Deck for session on Application Security at Limerick DotNet-Azure User Group on 15th Feb, 2018
Event URL:

  • Inicia sesión para ver los comentarios

  • Sé el primero en recomendar esto

For Business's Sake, Let's focus on AppSec

  1. 1. Lalit Kale @techiethought For Business’s sake, Let’s focus on AppSec Limerick DotNet Azure User Group (LDNA)
  2. 2. About Me • 12 years of .NET • Roles: Software Developer  Sr. Developer  Tech Lead Architect • Limerick DotNet Azure Meetup Organizer • AppSecurity Enthusiast Limerick DotNet Azure User Group (LDNA)
  3. 3. Our Sponsors Limerick DotNet Azure User Group (LDNA)
  4. 4. Before we start… • Audience: • Beginner .NET developers and developers coming from other non-windows background • Eventual pieces of new information/insights/ peek into future of .NET for Senior .NET developers • People who are keen on improving their craft • Presentation: • Approx. Time: ~1.30 Hour (45 min session +10-15 minutes of Pizza break + 10-15 minutes of questions) • Discussion Over Monotonous Delivery • Planned slides for Questions are marked with Question Icon, Feel free to jump in to express your thoughts or ask questions by raising your hands • Code Snippets to understand the concepts – Not Ready for Production • All Views/Opinions expressed here are mine and nothing to do with my current/past employers
  5. 5. Agenda • Understanding the Application Security and its business impact • OWASP • Threat Modelling • Secure Coding Practices • Penetration Testing and AppSec related Tools • What if, you are in middle of Attack scenarios
  6. 6. What is AppSec?
  7. 7. • Application security encompasses measures taken to improve the security of an application often • by finding, • fixing and • preventing security vulnerabilities. What is AppSec?
  8. 8. Getting Your Terms Right… • Asset: A resource of value such as the data in a database, money in an account, file on the filesystem or any system resource. • Vulnerability: A weakness or gap in security program that can be exploited by threats to gain unauthorized access to an asset. • Attack (or exploit): An action taken to harm an asset. • Threat Anything that can exploit a vulnerability and obtain, damage, or destroy an asset.
  9. 9. Business Impact Why AppSec is Important?
  10. 10. You don’t want to be… 145 million US Customers 400 k UK Customers 100 K Canadian Customers 1 billion300 K57 MGame of Thrones Manuscript
  11. 11. Source:
  12. 12. Live Attack Map
  13. 13. Every company is Software Company AppSec is for every business
  14. 14. AppSec
  15. 15. Foundations of Application Security • Authentication= (Who are you?) • Authorization=(What can you do?) • Auditing(Non-repudiation) =Can not deny your action • Confidentiality(Privacy)=Data remains private and confidential • Integrity=Data is protected • Availability=System remains available
  16. 16. Broader Picture - Layered Security Approach Physical Security Controlled Access, electronic surveillance ,video surveillance, security personnel Perimeter Security Firewalls, IDS Network Security Segmentation, Secure W-LAN , IPSec, DMZ Host Security Server Hardening, Client Hardening, Patch Management, Anti-virus, Distributed Firewalls Application Security IIS hardening, Exchange Hardening, SQL Server hardening,
  17. 17. Attacks are focusing on applications Sources: IBM X-Force, 2008 Operating system vs browser and application vulnerabilities 90% of vulnerabilities are remotely exploitable From the Microsoft Security Intelligence Report V7
  18. 18. Sources: Sept 2009 Report with data from TippingPoint IPS and vulnerability data by Qualys. Importance of Application Security • Web applications have largest number of vulnerabilities.
  19. 19. Web Applications Breach Perimeter Internet DMZ Trusted Inside Corporate Inside HTTP(S) Allows HTTP port 80 Allows HTTPS port 443 Firewall only allows applications on the web server to talk to application server. Firewall only allows application server to talk to database server. IIS Apache ASP .NET WebSphere Java MS-SQL Oracle DB2 Browser
  20. 20. OWASP • Open Web Application Security Project • International non-profit Project to make web applications more secure • Independent, reputable • Key goals • Awareness • Testing • Training •
  21. 21. OWASP Top 10 Threats - 2017Application Threat Negative Impact Example Impact Injection Flaws Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries. n data loss, corruption, or disclosure to unauthorized parties, loss of accountability, Broken Authentication & Session Management Session tokens not guarded or invalidated properly Hacker can “force” session token on victim; session tokens can be stolen after logout Sensitive Data Exposure Sensitive info sent unencrypted over insecure channel Unencrypted credentials “sniffed” and used by hacker to impersonate user XML External Entities (XXE) By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks. Broken Access Control Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers. The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record Security Misconfiguration Attackers can gain detailed system information Malicious system investigation may assist in developing further attacks Cross Site scripting Identity Theft, Sensitive Information Leakage, … Hackers can impersonate legitimate users, and control their accounts. Insecure Deserialization Attacker can access sensitive files and resources Web application returns contents of sensitive file (instead of harmless one) Missing Function Level Access Control Attacker can access unauthorized resources Hacker can forcefully browse and access a page past the login page Using Components with Known Vulnerabilities Attacker can exploit vulnerable component to gain access to system Attacker can do data loss and also perform server takeover. Insufficient Logging and Monitoring One strategy for determining if you have sufficient monitoring is to examine the logs following penetration testing. The testers' actions should be recorded sufficiently to understand what damages they In 2016, identifying a breach took an average of 191 days – plenty of time for damage to be inflicted.
  22. 22. DEMO OWASP Top 10 Threats (Project: WebGoat)
  23. 23. Security Professional “As a Security Professional, I don’t know how my companies web applications are supposed to work so I deploy a protective solution…but don’t know if it’s protecting what it’s supposed to.” Application Developers and QA “As an Application Developer, I can build/test great features and functions while meeting deadlines, but I don’t know how to develop/test my web application with security as a feature.” Industry Gap
  24. 24. Bridging The Gap-Step by Step • Prioritize application security as important non functional requirement • Improve awareness of application security in developers and QAs. • Incorporate security in SDLC. • Define clear role and responsibility towards application security • Promote Penetration testing of application
  25. 25. Education Accountability Administer and track security training Incident Response (MSRC) Establish release criteria and sign-off as part of FSR Ongoing Process Improvements Process Guide product teams to meet SDL requirements Microsoft Security Development Lifecycle
  26. 26. Threat Modelling • A Strategic framework for planning application security aspect in system design phase • Identify, understand, and mitigate threats most likely to affect the system • Can be practiced for both new applications as well as on existing ones
  27. 27. Threat Modelling Application Decomposition •Define scope •Create an architecture overview •Function •Logical architecture •Physical deployment •Technologies •Identify assets •Mark trust boundaries •Identify data flows, entry points, and assumptions •Make note of privileged code Threat Mapping •Identifying Threats •Use STRIDE Model •Creating Threat Tree •Documenting each Threat •STRIDE(Spoofing, Tampering, Repudiation, Information Disclosure, Elevation of Priviledges ) Calculate Risks •Use Risk = Probability * Damage Potential •Use Risk = Min(D, (D+R+E+A+D) / 5) •Damage •Reproducibility •Exploitability •Affected •Discoverability Risk Acceptance - doing nothing •Risk Transference - pass risk to an externality •Risk Avoidance - removing the feature/component that causes the risk •Risk Mitigation - decrease the risk •Mitigation strategies should be examined for each threat •Mitigations should be chosen according to the appropriate technology •Resolution should be decided according to risk level and cost of mitigations
  28. 28. Why Threat Modelling • Cannot build a secure system until you understand threats to system • Find security bugs early (and complex bugs) • Address threats in logical order according to greatest risk • Reduce overall risk by mitigating important threats • How do you know when application is “secure enough”?
  29. 29. Types of Threat Modelling • Attacker Centric Starts with an attack and evaluates the goals and how attackers might achieve them • Software Centric Starts from the design of system and attempts to step through a model of system, looking for types of attacks against each element of the model • Asset Centric Involves starting from assets entrusted to a system, such as a collection of sensitive personal information
  30. 30. Defense in Depth Example
  31. 31. SDL Core Principle: Least Privilege • Assume that all applications can and will be compromised • Least Privilege: If an application is compromised, then the potential damage that the malicious person can inflict is contained and minimized accordingly
  32. 32. Least Privilege Example LOCAL SYSTEMNON-ADMIN ADMIN / SYSTEM LEVEL • Read user files • Change system passwords • Download malicious files • Anything NON-ADMIN • Read user files • Change system passwords • Download malicious files • Limited capabilities
  33. 33. Least Privilege Tips • Evaluate your application and think minimally! • What is the minimum access level your application requires to perform its functions? • Elevate privileges only when needed, and then release those elevated privileges when their purposes have been satisfied
  34. 34. SDL Core Principle: Secure Defaults • Secure Defaults: Deploy applications in more secure configurations by default. • Helps to better ensure that customers get safer experience with your application out of the box, not after extensive configuration • It is up to the user to reduce security and privacy levels
  35. 35. Secure Defaults Examples Application Component Secure Defaults Principle Firewall Firewall ON by default SSL Socket Requires last latest SSL version (v3, TLS, etc.) by default User can access application anonymous or authenticated Application requires authenticated user sessions by default Password complexity can be enforced Password complexity is required by default Store user passwords as hashes or clear text Store user passwords as hashes by default
  36. 36. Secure Coding Practices 1. Validate input 2. Heed compiler warnings 3. Architect and design for security policies 4. Keep it simple. Keep the design as simple and small as possible 5. Default deny 6. Adhere to the principle of least privilege 7. Sanitize data sent to other systems 8. Practice defense in depth 9. Use effective quality assurance techniques 10. Incorporate Application Security through Continuous Integration 11. Adopt a secure coding standard – ndards
  37. 37. Tools Learning • Fiddler • WireShark • Chrome addins • OWSAP Static Code Analysis/Scanners • SonarQube • FxCop • Veracode • HP Fortify • Qualsys • Acunetix • NetSparker Pen Testing Tool • Kali-Linux • Metasploit • Burp Suite • OWSAP Zap – Integration with Jenkins CI Mobile Client Focused • Drozer • BEef Project • Frida • Mobile-Security- Framework- MobSF
  38. 38. Awesome List of PenTesting Resources •
  39. 39. When you are in middle of Attack • Identification • Use Threat Model that you have built to calculate your risk • Damage - how bad would an attack be? • Reproducibility - how easy is it to reproduce the attack? • Exploitability - how much work is it to launch the attack? • Affected users - how many people will be impacted? • Discoverability - how easy is it to discover the threat?
  40. 40. When you are in middle of Attack • Identify Attack Pattern • Man-in-Middle • DHCP Starvation • ARR Cache Poisoning • DNS Based attacks • DDoS • Social Engineering • Isolate – Reduce Attack Surface • Server Hardening – Closing ports, Blacklisting Ips/DNS Ranges • Implementation of Zero Trust Model (“never trust, always verify”) • Use of Deterrent Tools like IDS • Prevention is better than cure
  41. 41. Evolving Threats
  42. 42. . This presentation is shared under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license. More information for this license is available at All trademarks are the property of their respective owners. Lalit Kale or Limerick DotNet-Azure User Group or it’s members makes no warranties, express, implied or statutory, as to the information in this presentation. Limerick DotNet-Azure User Group Twitter: limerickdotnet