0. It’s No Longer the Network – Now It’s All About the Apps Joe Krull, CPP, CISSP, IAM, CISA, A.Inst.ISP, CRISC, CIPP Information Security Forum for Texas Government May 20, 2015

1. Presentation Overview
Traditional Network Security Activities Versus the New Reality
Basic Application Security (AppSec) Fundamentals
Risks Associated With Vulnerable Applications
Mobile (In)Security
Review Some Actual Vulnerability Data
What Can You Do to Help?
Tools and Resources to Assess and Audit AppSec Maturity

2. Traditional Network Security Centric Approach
Policies and Procedures
Patching and Configuration Changes
Network Scanning and Penetration Testing
Logging and Monitoring
Firewalls
Network Intrusion Detection/Prevention Systems
Anti-Virus and Endpoint Security
Security Info Event Systems

3. Myth #1 – I Don’t Need Application Security Because My Network is Secure
A common approach is to place a Web Application Firewall (WAF) in front of the organization's public facing web applications and ignore or de-emphasize application vulnerabilities and remediation. WAFs provide great capabilities, but only if they are properly deployed, correctly configured, regularly updated and actively monitored. WAFs can be placed in monitor/learning mode which would not proactively block attack attempts. Look at the photo on the right. Imagine that the fierce guard dogs are WAFs protecting a residence with no locks on the doors or windows and large amounts of cash and jewelry laying on the table in the entry hall. As long as the dogs are in place, hungry and alert, you have a deterrent and a means to protect the valuables. But what if the dogs are sleepy, distracted, over fed or even drugged. Your defenses will be significantly degraded.
Technical Rationale
Non-Technical Rationale

4. Application Security Fundamentals
Application security includes measures taken throughout an application's life-cycle to prevent exceptions in the security policy of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrade, or maintenance of the application.*
The primary focus is on Layer 7 of the OSI Model
AppSec should be part of an organization’s or vendor’s Software (or System) Development Life-Cycle (SDLC)
A key component of application security should be for developers and their managers to be aware of basic AppSec requirements, common threats and effective countermeasures
AppSec knowledge and maturity is significantly lower today than traditional network security
* Wikipedia

5. Risks Associated With Vulnerable Applications
Unauthorized access to sensitive citizen or organizational data
Theft of sensitive data to conduct identity theft, credit card fraud or other crimes
Defacement of websites; strong potential for brand/reputation damage
Manipulation of data impacting data integrity, quality and organization’s reputation
Redirection of users to malicious web sites; phishing and malware distribution
Denial of service; availability of data
Attackers can assume valid user identities
Access to hidden web pages using forged URLs
Attacker’s hostile data can trick the interpreter to execute unintended commands

6. The Attack Profile Continues to Change
Top Attacks By Product Type
Infrastructure 41.9%
Application 32.6%
ICS-SCADA 11.6%
Content Management Systems 11.6%
SSL/TLS 2.3 % (Heartbleed)
Most Exploited
OpenSSL TLS/DTLS Heartbleed
GNU Bash Variable Content
GNU Bash Variable Function Definitions
Drupal Core SQL Injection
Adobe Flash Player Remote Code Execution
Source: Cisco 2015 Annual Security Report

7. Let’s Look at Mobile Applications
Today’s large companies each spend an average of $34 million annually to develop mobile apps we use to shop, bank and more. However, only an average of 5.5% of this immense budget is spent on securing these apps against hackers and security.
Forty percent of companies do not scan the code in their mobile apps for security vulnerabilities
Fifty percent of companies have zero budget specifically earmarked for any security of their mobile applications
Source: March 2015 Ponemon/IBM Report of 400 Companies

8. Example High Risk Web Vulnerability

9. Brute Force Attack Vulnerability

10. Poor Application Password Management

11. Value and Risk Are Not Equally Distributed
Some Applications Matter More Than Others
Value and character of data being managed
Value of the transactions being processed
Cost of downtime and breaches
Therefore All Applications Should Not Be Treated the Same
Allocate different levels of resources to assurance
Select different assurance activities
Also must often address compliance and regulatory requirements

12. First Step – Application Inventory and Risk Ranking
The best place to begin any application security assessment is to obtain (or create) an inventory of all applications used by your organization. Include custom built, COTS, mobile, web, 3rd party developed and SaaS.
Risk rank the applications based on their criticality to the organization, the sensitivity of the data processed/stored and compliance requirements
Attempt to determine if the applications have been tested for security vulnerabilities and when. Examine contracts for 3rd party applications.

13. Next Step – Implement a Risk Based Approach
Determine the size and complexity of critical applications
Determine the underlying technology (Java, .net, Ruby, etc.)
Research the kinds of attacks directed against your types of applications
Perform or commission application security scanning coupled with manual testing
Prioritize the vulnerabilities and create a remediation plan
Follow up to determine that vulnerabilities are being remediated

14. Myth #2 – An Automated Scanner Can Find All The Application Vulnerabilities That Exist
There is no “silver bullet” for identifying application security vulnerabilities. There are different classes of tools ranging from static code scanners that assess the code to dynamic scanners that analyze logic and data flow. Generally, 30% to 40% of vulnerabilities can be identified by scanners; the remainder are uncovered by other means.
Manual testing allows an informed and experienced tester to attempt to manipulate the application, escalate privileges or get the application to operate in a way it was not designed to do.
But wait, there’s more…………

15. What Goes Into An Application Test?
Application security goes well beyond simply running a scanning tool. For critical or high value applications, or those that process sensitive data, thorough testing may actually include a combination of several methods.
Unauthenticated Automated Scan
Authenticated Automated Scan
Automated Binary Analysis
Blind Penetration Testing
Manual Source Code Review
Manual Binary Analysis
Informed Manual Testing
Automated Source Code Scanning

16. AppSec – What Can You Do and Why?
Information Security Professionals
Promote AppSec awareness in your organization
Confirm that application security testing is part of your overall security program
Demand that all applications developed by 3rd parties be tested and remediated prior to being placed in production
Get all developers and their managers trained on AppSec
Obtain and review the SDLC from a security perspective
IT Auditors
Influence your leaders to include AppSec in the organization’s annual risk assessment or audit plan
Increase your relevance and value to your organization by identifying risks associated with poorly coded applications
Conduct a simple initial audit to assess what controls are in place
Conduct a subsequent audit to determine the effectiveness of those controls; measure time to fix

17. Tools and Resources
Open Software Assurance Maturity Model (OpenSAMM) – A freely available open source framework that organizations can use to build and assess their software security programs
The Open Web Application Security Project (OWASP) – Worldwide not-for-profit organization focused on improving the security of software. Source of valuable free resources
Open Source or Low Cost Application Security Scanners – OWASP Zed Attack Proxy (ZAP), w3af, Mavituna Netsparker, Websecurify, Wapiti, N- Stalker, SkipFish, Scrawlr, Acunetix, and many more to do basic discovery work

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

19. The OWASP 2014 Top 10 For Mobile
M1 Weak Server Side Controls
M2 Insecure Data Storage
M3 Insufficient Transport Layer Security
M4 Unintended Data Leakage
M5 Poor Authorization and Authentication
M6 Broken Cryptography
M7 Client Side Injection
M8 Security Decisions Via Untrusted Inputs
M9 Improper Session Handling
M10 Lack of Binary Protections

20. Example AppSec Audit Work Program
Software Assurance Maturity Model (SAMM) Scorecard
Level 1
Maturity Level
Activity
Business Functions #
Security Practices/Phase A B
Governance 1
Strategy & Metrics
0.5 2
Policy & Compliance 3
Education & Guidance
Construction 4
Threat Assessment 5
Security Requirements 6
Secure Architecture
Verification 7
Design Review 8
Code Review 9
Security Testing
Deployment 10
Vulnerability Management 11
Environment Hardening 12
Operational Enablement
SAMM Valid Maturity Levels
Implicit starting point representing the activities in the Practice being unfulfilled
Initial understanding and ad hoc provision of Security Practice
Increase efficiency and/or effectiveness of the Security Practice
Comprehensive mastery of the Security Practice at scale
Legend
Objective Activity was met.
Objective Activity was not met.

21. Questions / Contact Information
Joe Krull
Director
(210)
blog.denimgroup.com