Presentation on theme: "Dealing with Web Application Security, Regulation Style"— Presentation transcript:
1Dealing with Web Application Security, Regulation Style Andrew Weidenhamer11/10/2010
2Agenda Why do we need Web Application Security How does PCI address Web Application SecurityshortcomingsHow does HIPAA, GLBA, and SOX address Web Application SecurityHow does FISMA address Web Application SecurityWhat about other industries?
3Why 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
4The Problem Custom coded web applications are very common Visual Studio, WebSphere, Eclipse, etc. are *almost* point and click solutionsASP.NET, Java, PHP allow for powerful web applications with minimal codingCustom Coded = Human Error75% of all external attacks occur at the application layer90% of web applications are vulnerable
5No 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 lifecycleEstimated 60+% of testing is production systemsLack of awareness of vendors/third party software companiesLack of awareness for outsourced developers
6Why Web Security? I have a Firewall and IDS What is vulnerable at the Web and Application layer?Financial DataPHI (Medical)PrivacyAm 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 ApplicationsIntrusion 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
8Requirement 66.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 customers6.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 environments6.4.2 Separation of duties between development/test and production environments
9Requirement 6 – Cont’d6.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 flaws6.5.2 Buffer overflow6.5.3 Insecure cryptographic storage6.5.4 Insecure communications6.5.5 Improper error handling6.5.6 All “High” vulnerabilities identified in the vulnerability identification processCross-site scriptingImproper Access ControlCross-site request forgery
10Requirement 6 – Cont’d6.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 changesInstalling a web-application firewall in front of public-facing web applications
11ShortcomingsWhy give the client a choice between code review and web application firewall?You can’t scan for the OWASP Top 10OWASP Top 10 is dynamicOnly requires scanning and code reviews for publically facing applications.Most ASV scanners do very little at the web application layerExternal Penetration Assessments can be performed by internal resourcesLevel 3 and 4 merchants
13How does HIPAA, GLBA, and SOX address Web Application Security?
14HIPAA – Access Controls Ensure that all system users have been assigned a unique identifierAnalyze workloads and operations to identify the access needs of all usersAnalyze workloads and operations to identify the access needs of all usersDevelop access control policyReview and update user accessImplement access control procedures using selected hardware and softwareEstablish an emergency access procedureTerminate access if it is no longer needed
15HIPAA – Audit ControlsDetermine the systems or activities that will be tracked or auditedSelect the tools that will be deployed for auditing and system activity reviewsDevelop and deploy the Information System Activity Review/Audit PolicyDevelop appropriate standard operating proceduresImplement the audit/system activity review process
16HIPAA – IntegrityIdentify any possible unauthorized sources that may be able to intercept the information and modify itDevelop the integrity policy and requirementsIdentify all users who have been authorized to access ePHIEstablish a monitoring process to assess how the implemented process is workingImplement procedures to address these requirements
17HIPAA – Person or Entity Authentication Determine authentication applicability to current systems/applicationsEvaluate authentication options availableSelect and implement authentication option
18HIPAA – Transmission Security Identify any possible unauthorized sources that may be able to intercept and/or modify the informationDevelop a transmission security policyImplement procedures for transmitting ePHI using Hardware/Software if needed
19What 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 requiredDepending 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)
23GLBA – Safeguards RuleDenoting at least one employee to manage the safeguardsConstructing a thorough risk management on each department handling the nonpublic informationDevelop, 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.
24GLBA - GuidanceSection 501(b) of GLBA requires Federal Financial Institutions Examination Council (FFIEC) member regulators to establish standards and guidelines for complying with the GLBA Safeguards RuleAccordingly, the regulators created the Interagency Guidelines Establishing Information Security Standards and the IT Examination Information Security HandbookBoth the Guidelines and Handbook require web application security if appropriate to the size and complexity of the financial institution
25GLBA – 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.
264. 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.
27GLBA – 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.
284. 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 theresults 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 processEstablishment of security requirementsEstablishment of acceptance criterionUse of secure coding standardsCompliance with security requirementsCode development and testing processesRestrictions on developer access to production source codePhysical security over developer work areasSource code reviewQuality and functionality of security patches
31SOXMost 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
32SOX - GuidanceThe 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
336) 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.
34ShortcomingsVirtually no controls around Security
35How does Federal Information Security Management Act (FISMA) address Web Application Security?
36FISMARequires 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 used to perform a risk analysisNIST controls will be required based on an agencies data risk classifications.NIST control areas such as System and Communications Protection are applicable to web applications.
37FISMA – System and Information Integrity Security AssessmentsVulnerability ScanningPolicies and ProceduresInformation Input ValidationError HandlingInformation Output Handling and Retention
38ShortcomingsGood..But not as prescriptive as PCI