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.

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)

20. Shortcomings

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

27. Shortcomings
VAGUE!!!!

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

31. Shortcomings
Virtually no controls around Security

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