Traditional information security mainly revolves around network and operating system (OS) level protection. Regardless of the level of security guarding those aspects, the system can be penetrated and the entire deployment can be brought down if your application's security isn't taken into serious consideration. Information security should ideally start at the application level, before network and OS level security is ensured. To achieve this, security needs to be integrated into the application at the software development phase. In this session, Dulanja will discuss the following: The importance of application security - why network and OS security is insufficient. Challenges in securing your application. Making security part of the development lifecycle.

1. Application Security - Your Success
Depends on it!

2. Why application security is important?
What sort of vulnerabilities affect applications?
What are the challenges in securing your application?
How to make security part of the development lifecycle?

3. Why application security is important?
● Applications deal with and act as the gateway for highly sensitive
enterprise assets like identifiable personal information, confidential
organizational information and credentials.
Examples: Patient Records Systems, Financial Systems, Insurance
Systems, Military Apps
● But application security is a highly neglected field in cybersecurity

6. ● One of the main reason for this staggering gap in application security is the
false sense of security felt by employing only perimeter/network protection
tools such as Packet Filters, Firewalls, Intrusion Detection and Prevention
Systems, and being satisfied by just hardening the OS and DB level
protection.
Image source: https://securityintelligence.com/the-10-most-common-application-attacks-in-action/

7. ● For example, a highly protected patient data store is allowed to be
accessed only via a single application. However, due to SQLi
vulnerabilities in the said application this sensitive datastore can be
breached.
● Web application vulnerabilities can cause: theft of critical business data
or personally identifiable information, web site defacement, or denial of
service.
● This could result in losses amounting to millions of dollars, and finally in
what each and every organization fears most: bad reputation - which can
mean the end of business.

8. ● To make the situation more complicated, your organization's attack surface
could be much larger than you imagine.
Attack Surface = No. of Apps x Avg number of serious vulnerabilities per app
● According to WhiteHat Security’s “WEB APPLICATIONS SECURITY
STATISTICS REPORT 2016”, across different industries, organizations have
hundreds, if not thousands, of consumer facing web applications, and each of
those websites has anywhere from 5 to 32 vulnerabilities per website. This
means that there could be thousands of vulnerabilities across your web
applications.

9. - WhiteHat Security’s “WEB APPLICATIONS
SECURITY STATISTICS REPORT 2016”

10. JP Morgan Breach
● Leak of one of the largest number of records to date. It affected an estimated
76 million households and 7 million small businesses.
● Compromised user contact information, which includes the names, addresses,
phone numbers, email addresses, and others
● Attackers got their hands on a list of apps and programs used in JP Morgan
systems, which they likely double-checked for available flaws they can use.
● They attacked through a zero-day vulnerability or a new flaw which was
present in the affected websites.
Reference: http://www.trendmicro.com/vinfo/us/security/news/cyber-attacks/jp-morgan-breach-affects-millions-shows-need-for-secure-web-apps

11. Bell Canada Breach
● One of the biggest security breaches of a Canadian company in recent
memory.
● Company said 22,421 usernames and passwords, and 5 valid credit card
numbers were stolen. However, other sources say about 40,000 customer
records were affected.
● Attack was by POST SQL injection. The vulnerable url was Bell’s protection
management login page:
https://protectionmanagement.bell.ca/passwordrecovery_1.asp.
References: http://o.canada.com/technology/bell-canada-security-breach-391451
https://www.databreaches.net/nullcrew-attack-on-bell-canada-was-sql-injection-and-bell-knew-weeks-ago-nullcrew/

12. What are the vulnerabilities?
OWASP Top 10
A1 Injection
A2 Broken Authentication and Session Management
A3 Cross Site Scripting (XSS)
A4 Insecure Direct Object References
A5 Security Misconfiguration
A6 Sensitive Data Exposure
A7 Missing Function Level Access Control
A8 Cross Site Request Forgery (CSRF)
A9 Using Components with Known Vulnerabilities
A10 Unvalidated Redirects and Forwards
Reference: https://www.owasp.org/index.php/Top_10_2013-Top_10

13. Injection
● Use a parameterized API (e.g. Java PreparedStatement).
● If an API is not available, escape harmful special characters.
● Use “white list” input validation. But it is not a complete defense as
many applications require special characters in their input.

14. ● Store passwords as salted hashes.
● Enforce hard to guess passwords via password policies.
● Disable URL rewriting - stop session IDs getting passed in URLs.
● Make sure sessions get timed out and properly invalidated after
logout.
● Renew session ID with each successful login.
● Send passwords, session IDs and other credentials over encrypted
connections.
Broken Authentication and Session Management

15. Cross Site Scripting (XSS)
● Properly escape all the untrusted data based on HTML context
(body, attribute, JS, CSS, URL).
● Do server-side input validation.

16. ● Make sure user has authorization to access the resource.
● Use indirect object references.
Insecure Direct Object References

17. Security Misconfiguration
● Keep everything up to date (e.g. security patches).
● Remove unnecessary features.
● Remove default accounts and passwords.
● Use custom error pages.
● Configure proper HTTP security headers.
● Avoid using default keystores.

18. ● Store sensitive information encrypted.
● Discard any data that is not needed.
● Make sure data are transmitted over HTTPS.
● Use strong standard cryptographic algorithms - do not invent your own algo!
● Use salted hashes to store passwords.
● Avoid browsers and proxies caching sensitive pages by sending cache
prevention headers.
Sensitive Data Exposure

19. Missing Function Level Access Control
● Make sure server side privilege checks are done when accessing
restricted functions.
● Avoid displaying UI sections that are not allowed to be navigated for
a given privilege.

20. ● Generate an unpredictable token (could be per session or per
request) and get it submitted with each form post and validate it.
● Use a specialized library like OWASP CSRFGuard
Cross Site Request Forgery (CSRF)

21. Using Components with Known Vulnerabilities
● Monitor the security of third party components in public databases,
project mailing lists, and security mailing lists, and keep them up to
date.
● Consider adding security wrappers around components to disable
unused functionality and/ or secure weak or vulnerable aspects of
the component.

22. ● Don’t involve user parameters in calculating the destination.
● If parameters can’t be avoided, ensure that the supplied value is
valid, and authorized for the user.
● When using parameters use a mapping value, rather than the actual
URL or portion of the URL. Server side code should translate this
mapping to the target URL.
Unvalidated Redirects and Forwards

23. Image source: https://www.veracode.com/directory/owasp-top-10

24. What are the challenges?
● Security is a non-functional requirement
● Security is not a priority in Management’s PoV
● Tight/rapid deadlines caused by agile/prototype approaches
● Mindset/attitude of the architects/developers
● Limited or no awareness of security vulnerabilities and secure SDLC best
practices among technical personnel
● Minds not trained to think like a hacker

25. What are the challenges? contd...
● Tracking security status of hundreds of applications is no easy task
● Cost of automated commercial security scanning softwares
● Dealing with thousands of false positives
● Finding resources to deal with internally and externally reported
vulnerabilities

26. How to make security part of SDLC?
● Form a security team to govern and drive the organizational security
● Initiate security awareness programs for C-level executives, Architects
and Developers. This can be even make part of the orientation programs
for new employees. Current security threats, trends and best practices
(coding and deployment) are some topics to cover. Correct the mindset!
● Create security policies to adhere to at the SDLC level. These could be
design review policies, code review policies, product release policies and
etc.

27. ● Introduce threat modelling at the design phase
Example tool: Microsoft’s SDL Threat Modeling Tool
What is threat modelling?
● A structured mechanism to identify, quantify and address security risks of an
application.
● Documents all the entry points in the system, assets and trust levels.
● Commonly has 3 steps:
1. Decompose the Application
2. Determine and rank threats
3. Determine countermeasures and mitigation
STRIDE is a threat categorization model that can be used in Step 2
S = Spoofing identity
T = Tampering with data
R = Repudiation
I = Information Disclosure
D = Denial of service
E = Elevation of privilege

28. ● Do Software Composition Analysis (SCA) at the design phase
Example tool:
➔ OWASP Dependency Check
What is SCA?
● 3rd party components could make an otherwise secure system vulnerable.
● SCA is analysis of the 3rd party components for any known vulnerabilities.
● Analysis would be run against a vulnerability repository like National
Vulnerability Database (NVD).
● This helps to mitigate OWASP’s “A9 - Using Components with Known
Vulnerabilities”

29. ● Mandate static/dynamic application security testing (SAST & DAST) in
development phase.
Example tools:
➔ FindSecurityBugs (a FindBugs plugin) for static analysis
➔ OWASP ZAP (Zed Attack Proxy) for dynamic analysis
What is SAST?
● Analysing the source code or bytecode for any security vulnerabilities.
● This is white box testing.
What is DAST?
● Analysing for vulnerabilities at the application run time by attacking the
URLs or by using any information available to the outside world.
● This is black box testing.

30. ● Setup automated security testing at the integration phase.
○ E.g. integrate OWASP Dependency Check, FindSecurityBugs and
OWASP ZAP with Jenkins
● Setup interactive application security testing (IAST) in development and
integration phases:
Commercial software are available for this.
What is IAST?
● This could be treated as a hybrid model of SAST and DAST.
● An agent instruments the application and does all of the analysis in real time.
● Agent has access to: all the code for the application, runtime information, HTTP
requests and responses and many more.
● Minimizes false positives due to the availability of more information

31. ● Conduct manual penetration testing.
● Follow a risk based security management approach
○ Maintain a repository of applications and their impact on the business
○ Test applications for vulnerabilities
○ Evaluate the risk and prioritize what to be fixed
○ Allocate resources and fix according to the priority

32. Questions?

33. Thank You!