dealing with web application security, regulation style andrew weidenhamer 11/10/2010

41
Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Upload: johnny-hambleton

Post on 31-Mar-2015

221 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Dealing with Web Application Security, Regulation Style

Andrew Weidenhamer11/10/2010

Page 2: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Agenda

•Why do we need Web Application Security•How does PCI address Web Application

Security shortcomings

•How does HIPAA, GLBA, and SOX address Web Application Security shortcomings

•How does FISMA address Web Application Security shortcomings

•What about other industries?

Page 3: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Why do we need Web Application Security?

After being edged out in 2008 as the most-used path ofintrusion, web applications now reign supreme in both

thenumber of breaches and the amount of data

compromisedthrough this vector. Both Verizon and USSS cases show

thesame trend. Web applications have the rather

unfortunatecalling to be public-facing, dynamic, user-friendly, and

secure all at the same time. Needless to say, it’s a tough job.

- Verizon 2010 Data Breach Statistics Report

Page 4: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

The Problem

•Custom coded web applications are very common Visual Studio, WebSphere, Eclipse, etc.

are *almost* point and click solutions ASP.NET, Java, PHP allow for powerful

web applications with minimal coding•Custom Coded = Human Error•75% of all external attacks occur at the

application layer•90% of web applications are vulnerable

Page 5: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

• No Windows Update for web based applications – multiple technologies involved

• Lack of awareness of application developers, application owners, architects, system administrators, etc.

• Security not embedded into the software development lifecycle

• Estimated 60+% of testing is production systems

• Lack of awareness of vendors/third party software companies

• Lack of awareness for outsourced developers

Page 6: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Why Web Security? I have a Firewall and IDS

• Am I Safe with a Firewall? - Many companies are filtering their Internet connection (Block ALL except 80 & 443)

Port 80/443 – Permits access to the Web Server and Web Applications

• Intrusion Detection Systems? – DETECT Signatures and DON’T work on custom coded applications.

• What is vulnerable at the Web and Application layer? Financial Data PHI (Medical) Privacy

• What about anti-virus software?– Code RED exploited by virus/worm – Attacked Microsoft IIS Web Server

Page 7: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

How does PCI address Web Application

Security?

Page 8: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

• 6.3 Develop software applications (internal and external, and including web-based administrative access to applications) in accordance with PCI DSS (for example, secure authentication and logging), and based on industry best practices. Incorporate information security throughout the software development life cycle.

• 6.3.1 Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers

• 6.3.2 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.

• 6.4.1 Separate development/test and production environments

• 6.4.2 Separation of duties between development/test and production environments

Requirement 6

Page 9: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Requirement 6 – Cont’d

• 6.5 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following: 6.5.1 Injection flaws, particularly SQL injection. Also consider

OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws

6.5.2 Buffer overflow 6.5.3 Insecure cryptographic storage 6.5.4 Insecure communications 6.5.5 Improper error handling 6.5.6 All “High” vulnerabilities identified in the vulnerability

identification process Cross-site scripting Improper Access Control Cross-site request forgery

Page 10: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Requirement 6 – Cont’d

• 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Reviewing public-facing web applications via manual or

automated application vulnerability security assessment tools or methods, at least annually and after any changes

Installing a web-application firewall in front of public-facing web applications

Page 11: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Shortcomings•Why give the client a choice between code

review and web application firewall?

•You can’t scan for the OWASP Top 10

•OWASP Top 10 is dynamic

•Only requires scanning and code reviews for publically facing applications.

•Most ASV scanners do very little at the web application layer

•External Penetration Assessments can be performed by internal resources

•Level 3 and 4 merchants

Page 12: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

PROOF!!!

Page 13: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

How does HIPAA, GLBA, and SOX address Web Application Security?

Page 14: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

HIPAA – Access Controls

• Analyze workloads and operations to identify the access needs of all users

• Analyze workloads and operations to identify the access needs of all users

• Ensure that all system users have been assigned a unique identifier

• Implement access control procedures using selected hardware and software

• Review and update user access

• Establish an emergency access procedure

• Terminate access if it is no longer needed

• Develop access control policy

Page 15: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

HIPAA – Audit Controls

• Determine the systems or activities that will be tracked or audited

• Select the tools that will be deployed for auditing and system activity reviews

• Develop and deploy the Information System Activity Review/Audit Policy

• Develop appropriate standard operating procedures

• Implement the audit/system activity review process

Page 16: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

HIPAA – Integrity

• Identify all users who have been authorized to access ePHI

• Identify any possible unauthorized sources that may be able to intercept the information and modify it

• Develop the integrity policy and requirements

• Implement procedures to address these requirements

• Establish a monitoring process to assess how the implemented process is working

Page 17: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

HIPAA – Person or Entity Authentication

• Determine authentication applicability to current systems/applications• Evaluate

authentication options available

• Select and implement authentication option

Page 18: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

HIPAA – Transmission Security

• Identify any possible unauthorized sources that may be able to intercept and/or modify the information

• Develop a transmission security policy

• Implement procedures for transmitting ePHI using Hardware/Software if needed

Page 19: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

What did we notice about HIPAA?

Web application security is not specifically called out in the HIPAA Security Rule, however:

•A risk analysis and risk assessment is required

•Depending on the risk rating, entities may need to ensure proper security controls are in place for web applications associated with electronic protected health information (ePHI)

Page 20: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Shortcomings

Page 21: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

PROOF!!!

Page 22: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

PROOF #2!!!

Page 23: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

GLBA – Safeguards Rule

•Denoting at least one employee to manage the safeguards

•Constructing a thorough risk management on each department handling the nonpublic information

•Develop, monitor, and test a program to secure the information and,

•Change the safeguards as needed with changes in how information is collected, stored and used.

Page 24: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

GLBA - Guidance

•Section 501(b) of GLBA requires Federal Financial Institutions Examination Council (FFIEC) member regulators to establish standards and guidelines for complying with the GLBA Safeguards Rule

•Accordingly, the regulators created the Interagency Guidelines Establishing Information Security Standards and the IT Examination Information Security Handbook

•Both the Guidelines and Handbook require web application security if appropriate to the size and complexity of the financial institution

Page 25: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

GLBA – Guidance (cont’d)

G. APPLICATION SECURITY (IT EXAMINATION INFORMATION SECURITY HANDBOOK)

1.Determine whether software storage, including program source, object libraries, and load modules, are appropriately secured against unauthorized access.

2.Determine whether user input is validated appropriately (e.g. character set, length, etc).

3.Determine whether appropriate message authentication takes place.

Page 26: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

4.Determine whether access to sensitive information and processes require appropriate authentication and verification of authorized use before access is granted.

5.Determine whether re-establishment of any session after interruption requires normal user identification, authentication, and authorization.

6.Determine whether appropriate warning banners are displayed when applications are accessed.

7.Determine whether appropriate logs are maintained and available to support incident detection and response efforts.

Page 27: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

GLBA – Guidance (cont’d)H. SOFTWARE DEVELOPMENT (IT

EXAMINATION INFORMATION SECURITY HANDBOOK)

1. Inquire about how security control requirements are determined for software, whether internally developed or acquired from a vendor.

2. Determine whether management explicitly follows a recognized security standard development process, or adheres to widely recognized industry standards.

3. Determine whether the group or individual establishing security control requirements has appropriate credentials, background, and/or training.

 

Page 28: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

4. Inquire about the method used to test the newly developed or acquired software for vulnerabilities. For manual source code reviews, inquireabout standards used, the capabilities of the reviewers, and the results of the reviews. If source code reviews are not performed, inquire about alternate actions taken to test the software for covert channels, backdoors, and other security issues.

5. Evaluate the process used to ascertain software trustworthiness. Include in the evaluation management’s consideration of the:

• Development process• Establishment of security requirements• Establishment of acceptance criterion• Use of secure coding standards• Compliance with security requirements• Code development and testing processes• Restrictions on developer access to production source code• Physical security over developer work areas• Source code review• Quality and functionality of security patches

Page 29: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Shortcomings

VAGUE!!!!

Page 30: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

PROOF!!!

Page 31: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

SOX

•Most corporate financial records are accessed and maintained in electronic formats that often have Web-based components, there is a significant correlation between this information and Web applications.

•Section 404 requires companies have in place appropriate, enterprise-wide controls to protect the integrity of financial data as well as the systems that access the data

Page 32: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

SOX - Guidance

The development controls with a SOX perspective include: 1) Documented policy and procedures 2) Developers/ IT managers are trained on the procedures 3) Standard controls such as business owners approve the design, 4) Development is carried over as per standards, functional specifications 5) Separate test environment for development/ test/ production / test plans

Page 33: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

6) Segregation of duties ( The developer who created and cannot pass his own test, cannot promote the code to production etc) 7) Business owner’s testing and approval before changes/ app goes into production 8) Good Version Control Program to ensure that older versions are kept available 9) Source Code is properly secured 10) Built in user access controls for authentication and prevention of fraud.

Page 34: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Shortcomings

Virtually no controls around Security

Page 35: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

How does Federal Information Security

Management Act (FISMA) address Web Application Security?

Page 36: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

FISMA•Requires each federal agency to develop,

document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

•NIST 800-30 used to perform a risk analysis

•NIST 800-53 controls will be required based on an agencies data risk classifications.

•NIST 800-53 control areas such as System and Communications Protection are applicable to web applications.

Page 37: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

FISMA – System and Information Integrity

•Security Assessments

•Vulnerability Scanning

•Policies and Procedures

•Information Input Validation

•Error Handling

•Information Output Handling and Retention

Page 38: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Shortcomings

Good..But not as prescriptive as PCI

Page 39: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

What about other industries?

Page 40: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Privacy??

•Legal

•Manufacturing

•Retail

•Business Services

Page 41: Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 11/10/2010

Thank you for your time!

AQA N S W E R SA N S W E R SQ U E S T I O N Q U E S T I O N SS

E: [email protected]

m