Dealing with Web Application Security, Regulation Style

1. Dealing with Web Application Security, Regulation Style • Andrew Weidenhamer • 11/10/2010

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

3. Why do we need Web Application Security? After being edged out in 2008 as the most-used path of intrusion, web applications now reign supreme in both the number of breaches and the amount of data compromised through this vector. Both Verizon and USSS cases show the same trend. Web applications have the rather unfortunate calling 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

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

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

6. Why Web Security? I have a Firewall and IDS • What is vulnerable at the Web and Application layer? • Financial Data • PHI (Medical) • Privacy • 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 about anti-virus software?– Code RED exploited by virus/worm – Attacked Microsoft IIS Web Server

7. How does PCI address Web Application Security?

8. Requirement 6 • 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

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

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

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

12. PROOF!!!

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

14. HIPAA – Access Controls • Ensure that all system users have been assigned a unique identifier • Analyze workloads and operations to identify the access needs of all users • Analyze workloads and operations to identify the access needs of all users • Develop access control policy • Review and update user access • Implement access control procedures using selected hardware and software • Establish an emergency access procedure • Terminate access if it is no longer needed

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

16. HIPAA – Integrity • Identify any possible unauthorized sources that may be able to intercept the information and modify it • Develop the integrity policy and requirements • Identify all users who have been authorized to access ePHI • Establish a monitoring process to assess how the implemented process is working • Implement procedures to address these requirements

17. HIPAA – Person or Entity Authentication • Determine authentication applicability to current systems/applications • Evaluate authentication options available • Select and implement authentication option

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

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

20. Shortcomings

21. PROOF!!!

22. PROOF #2!!!

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

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

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

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

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

28. 4. Inquire about the method used to test the newly developed or acquired software for vulnerabilities. For manual source code reviews, inquire about 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

29. Shortcomings VAGUE!!!!

30. PROOF!!!

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

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

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

34. Shortcomings Virtually no controls around Security

35. How does Federal Information Security Management Act (FISMA) address Web Application Security?

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

37. FISMA – System and Information Integrity • Security Assessments • Vulnerability Scanning • Policies and Procedures • Information Input Validation • Error Handling • Information Output Handling and Retention

38. Shortcomings Good..But not as prescriptive as PCI

39. What about other industries?

40. Privacy?? • Legal • Manufacturing • Retail • Business Services

41. Thank you for your time! Q A Q U E S T I O N S A N S W E R S E: aweidenhamer@securestate.com