SlideShare a Scribd company logo

Dealing with Web Application Security, Regulation Style

•
•
Rochester Security Summit
Rochester Security Summit

Because many organizations don't perform security unless they have to, more than 80% of all web applications are being exposed to vulnerabilities. In comes regulation. There are a number of different industries other than financial and healthcare that deal with PII and PHI but are either not regulated at all or are regulated very loosely. This presentation will discuss the various regulations (PCI, SOX, HIPAA, etc.) and what each does to address web application security, if any, as well as the shortcomings of each. Finally, it will further address industries that need to be more strictly regulated in order to better protect personal information. Andrew Weidenhamer, Senior Security Consultant, SecureState Andrew Weidenhamer, Senior Security Consultant, joined SecureState in January 2008. As a former member of the Profiling Team, Andrew performed technical security assessments on a weekly basis. These assessments included Internal and External Attack and Penetration Assessments, Wireless Penetration Assessments, Web Application Security Reviews, Physical Penetration Tests, and Social Engineering Assessments.

Related slideshows

Securing and automating your application infrastructure meetup 23112021 b
Securing and automating your application infrastructure meetup 23112021 bSecuring and automating your application infrastructure meetup 23112021 b
Securing and automating your application infrastructure meetup 23112021 b
 
Delivering Security Within the MAX Remote Management Platform - Todd Haughland
Delivering Security Within the MAX Remote Management Platform - Todd HaughlandDelivering Security Within the MAX Remote Management Platform - Todd Haughland
Delivering Security Within the MAX Remote Management Platform - Todd Haughland
 
NTXISSACSC2 - Securing Industrial Control Systems by Kevin Wheeler
NTXISSACSC2 - Securing Industrial Control Systems by Kevin WheelerNTXISSACSC2 - Securing Industrial Control Systems by Kevin Wheeler
NTXISSACSC2 - Securing Industrial Control Systems by Kevin Wheeler
 
1 of 38
Download to read offline
Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 10/21/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?
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
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
• 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 on production systems • Lack of awareness by vendors/third party software companies • Lack of awareness by outsourced developers
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 • What about anti-virus software?– Code RED exploited by virus/worm – Attacked Microsoft IIS Web Server • 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
How Does PCI Address Web Application Security?
Requirement 6 6.3 – Develop software application in accordance with PCI DSS and based on industry best practices, and incorporate information security throughout the software development life cycle 6.3.1 – Testing of all security patches and system and software configuration changes before deployment including but not limited to the following: • Validation of all input • Validation of proper error handling • Validation of secure communications • Validation of proper role-based access control 6.3.2 – Separate development/test and production environment 6.3.3 – Separation of duties between development/test and production environments 6.3.6 – Removal of custom applications accounts, user IDs, and passwords before applications become active or are released to customers 6.3.7 – Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability
Requirement 6 (Cont’d.) 6.4 – Follow change control procedures for all changes to system components 6.5 - Develop all web applications based on secure coding guidelines such as the OWASP 6.6 – For public-facing web applications ensure that either one of the following methods are utilized: • Verify that public-facing web applications are reviewed or; • Verify that a web application firewall is in place
Dealing with Web Application Security, Regulation Style
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 public- 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
PROOF!!! <PICTURE OF HACKED APPLICATION RESULTING IN CARDHOLDER DATA EXPOSURE>
How Does HIPAA, GLBA, and SOX Address Web Application Security?
• Analyze workloads and operations to identify the access needs of all users • Identify all data and systems where access control is a requirement • Ensure that all system users have been assigned a unique identifier • Develop access control policy • 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 HIPAA – Access Controls
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
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
HIPAA – Person or Entity Authentication • Determine authentication applicability to current systems/applications • Evaluate authentication options available • Select and implement authentication option
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
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 are 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)
Shortcomings
PROOF!!! <PICTURE OF HACKED APPLICATION RESULTING IN ePHI EXPOSURE>
PROOF #2!!! <PICTURE OF HACKED APPLICATION RESULTING IN ePHI EXPOSURE>
• 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 GLBA – Safeguards Rule
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
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. 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.
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. 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
Shortcomings VAGUE!!!!
PROOF!!! <PICTURE OF HACKED APPLICATION RESULTING IN GLBA RELATED DATA EXPOSURE>
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 thatcompanies have in place appropriate, enterprise-wide controls to protect the integrity of financial data as well as the systems that access the data.
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 6) Segregation of duties 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
Shortcomings Virtually no controls around Security
How Does Federal Information Security Management Act (FISMA) Address Web Application Security?
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 agency’s data risk classifications. • NIST 800-53 control areas such as System and Communications Protection are applicable to web applications.
FISMA – System and Information Integrity • Security Assessments • Policies and Procedures • Malicious Code Protection • Information System Monitoring • Information Input Validation • Error Handling • Information Output Handling and Retention
Shortcomings Good..But not as prescriptive as PCI
What About Other Industries?
Privacy? • Legal • Manufacturing • Retail • Business Services
Thank You For Your Time! Q U E S T I O N S A N S W E R S

More Related Content

Dealing with Web Application Security, Regulation Style

  • 1. Dealing with Web Application Security, Regulation Style Andrew Weidenhamer 10/21/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 on production systems • Lack of awareness by vendors/third party software companies • Lack of awareness by outsourced developers
  • 6. 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 • What about anti-virus software?– Code RED exploited by virus/worm – Attacked Microsoft IIS Web Server • 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
  • 7. How Does PCI Address Web Application Security?
  • 8. Requirement 6 6.3 – Develop software application in accordance with PCI DSS and based on industry best practices, and incorporate information security throughout the software development life cycle 6.3.1 – Testing of all security patches and system and software configuration changes before deployment including but not limited to the following: • Validation of all input • Validation of proper error handling • Validation of secure communications • Validation of proper role-based access control 6.3.2 – Separate development/test and production environment 6.3.3 – Separation of duties between development/test and production environments 6.3.6 – Removal of custom applications accounts, user IDs, and passwords before applications become active or are released to customers 6.3.7 – Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability
  • 9. Requirement 6 (Cont’d.) 6.4 – Follow change control procedures for all changes to system components 6.5 - Develop all web applications based on secure coding guidelines such as the OWASP 6.6 – For public-facing web applications ensure that either one of the following methods are utilized: • Verify that public-facing web applications are reviewed or; • Verify that a web application firewall is in place
  • 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 public- 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!!! <PICTURE OF HACKED APPLICATION RESULTING IN CARDHOLDER DATA EXPOSURE>
  • 13. How Does HIPAA, GLBA, and SOX Address Web Application Security?
  • 14. • Analyze workloads and operations to identify the access needs of all users • Identify all data and systems where access control is a requirement • Ensure that all system users have been assigned a unique identifier • Develop access control policy • 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 HIPAA – Access Controls
  • 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 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
  • 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 are 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)
  • 21. PROOF!!! <PICTURE OF HACKED APPLICATION RESULTING IN ePHI EXPOSURE>
  • 22. PROOF #2!!! <PICTURE OF HACKED APPLICATION RESULTING IN ePHI EXPOSURE>
  • 23. • 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 GLBA – Safeguards Rule
  • 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. 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.
  • 26. 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. 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
  • 28. PROOF!!! <PICTURE OF HACKED APPLICATION RESULTING IN GLBA RELATED DATA EXPOSURE>
  • 29. 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 thatcompanies have in place appropriate, enterprise-wide controls to protect the integrity of financial data as well as the systems that access the data.
  • 30. 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 6) Segregation of duties 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
  • 32. How Does Federal Information Security Management Act (FISMA) Address Web Application Security?
  • 33. 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 agency’s data risk classifications. • NIST 800-53 control areas such as System and Communications Protection are applicable to web applications.
  • 34. FISMA – System and Information Integrity • Security Assessments • Policies and Procedures • Malicious Code Protection • Information System Monitoring • Information Input Validation • Error Handling • Information Output Handling and Retention
  • 35. Shortcomings Good..But not as prescriptive as PCI
  • 36. What About Other Industries?
  • 37. Privacy? • Legal • Manufacturing • Retail • Business Services
  • 38. Thank You For Your Time! Q U E S T I O N S A N S W E R S