Slide-Deck for session on Application Security at Limerick DotNet-Azure User Group on 15th Feb, 2018 Event URL: https://www.meetup.com/Limerick-DotNet/events/hzctdpyxdbtb/

1. Lalit Kale
@techiethought
For Business’s sake, Let’s focus on
AppSec
Limerick DotNet Azure User Group (LDNA)

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. Our Sponsors
Limerick DotNet Azure User Group (LDNA)

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. 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. What is AppSec?

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. 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. Business Impact
Why AppSec is Important?

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. Source: https://www.accenture.com/t20170926T072837Z__w__/us-en/_acnmedia/PDF-61/Accenture-2017-CostCyberCrimeStudy.pdf

12. Live Attack Map

13. Every company is Software Company
AppSec is for every business

14. AppSec

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. 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. 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. 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. 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. OWASP
• Open Web Application Security Project
• International non-profit Project to make web applications more
secure
• Independent, reputable
• Key goals
• Awareness
• Testing
• Training
• www.owasp.org

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. DEMO
OWASP Top 10 Threats (Project: WebGoat)https://www.dbramante1928.com/mini-profiler-resources/results

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. 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. 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. 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. 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. 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. 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. Defense in Depth Example

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. 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. 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. 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. 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. 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 –
https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Sta
ndards
https://msdn.microsoft.com/en-us/library/ff649874.aspx

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. Awesome List of PenTesting Resources
• https://github.com/enaqx/awesome-pentest

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

42. Evolving Threats

43. .
This presentation is shared under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license. More information for this license is available at http://creativecommons.org/licenses/by-nc-sa/4.0/
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
https://www.meetup.com/limerick-dotnet/
Twitter: limerickdotnet