Securing and Modernizing Applications for Texas State Agencies
John Dickson, CISSP
Dan Cornell
D C ll
Gregory Genung
August 26, 2009
g ,

Agenda
• Background
• Introductions
• Problem: Legacy Application Proliferation
• Solution: Secure and Modernize
• Strategies
• Questions
• More Information
1

Denim Group Background
• Privately-held, professional services organization that develops
secure software and mitigates risk with existing software
• Trusted partner of numerous State of Texas Agencies
• Development p p
p perspective influences all aspects of software security
p y
– All consultants regularly build software systems
– Approach the problem of software security from a developers viewpoint
• Thought Leaders in Secure Development Practices
g p
– Developed Sprajax – First Open Source AJAX vulnerability scanner
– National speakers at conference such as RSA
– OWASP National Leaders and Local Chapter
2

Denim Group DIR Contract: DIR SDD 660
• External Controlled Penetration Testing
– Application Assessments
IT Security Services
• Risk and Vulnerability Assessment Services
– Application Penetration Testing
– Secure Code Reviews
– Secure Application Development Services
– Commercial Product Assessment
– Data Security Assessment
• Security Training Services
– Application Security Principles Training
3

Introductions
• Name
• Organization
• Role
• Current Challenges and Desired Takeaways
4

Challenges with Legacy Applications
5

Challenges with Legacy Applications
• Construction
– Targeted at non-web platforms
– Little or no thought of security
– Compliance and governance regimes have come into existence after application
was originally built
• Management
g
– State of the industry has advanced
– Older technologies lack modern management and monitoring capabilities
– Multiple platforms, multiple technologies
• Skill sets and knowledge
– Talent pool is shrinking for legacy platforms and languages
– Little or no knowledge of application requirements
6

Opportunity
7

Opportunity
• Piggyback on data center migration to accomplish complementary goals
• Move to supported platforms
• Where appropriate and convenient – combine applications
• Bring applications back to life
• Build security in
y
• Allow for management and monitoring
8

Process
• Enumerate
• Classify
• Plan
• Remediate
9

Enumerate
10

Enumerate
• What applications are you running?
– How many instances?
• Do
D you hhave th source code?
the d ?
• Do you have documentation?
• Who owns the applications?
• What are the politics of remediating the application?
11

Classify
12

Classify
• What sort of data does the application manage?
– PII
– PHI
– Credit cards
– Information about minors
– Criminal background information
g
• What technologies and platforms are in use?
• Which applications are considered “mission critical”?
• What is the volume and value of transactions?
• How many and what types of users?
13

Plan
14

Plan - Portfolio
• Prioritize based on risk and value
• Walk before you run – drive risk out of the process
• Craft an organizational framework for remediated applications
• Are there other mandates?
– “Drop dead” dates tied to budgets
• Opportunities for data sharing and business Intelligence
• Processes and technologies for modern development
– Continuous integration
– Automated testing
– Agile development
15

Plan - Application
• Different Approaches
– Migrate to data center as-is
– Remediate existing application
– Remediate via automated conversion
– Remediate via rewrite
• Determine security and compliance requirements from the outset
– World today is different than when applications were originally created
• Data center performance requirements
• Accessibility requirements
• How will you test the final application?
– Automated testing has made great strides – xUnit, QASL
• Who ill
Wh will own and manage th application after it i remediated?
d the li ti ft is di t d?
16

Migration
17

Migrate As-Is
• Low cost / high risk
• May require an exception from datacenter
• Potential for reduced/no support
• Application issues still exist
– Security, quality, maintainability, compliance, accessibility, performance
• “We plan to ‘end-of-life’ this application”
– Really? For how long?
18

Remediate Existing Application (Upgrade)
• Upgrade platform version
– JDK or .NET version, application server version
– May be required for support in the datacenter
• Address security vulnerabilities and functionality that is non-compliant
• Use automated tools and automated functional tests as a guide
– S t a standard f personnel d i remediation
Sets t d d for l doing di ti
• Refactor to increase quality and maintainability
• Incrementally adopt best practices
– Create automated tests
– Start continuous integration
– Secure coding standards for all new code
– Instrument for monitoring
19

Remediate via Automated Conversion
20

Remediate via Automated Conversion
• Automated conversion from one platform to another
– Example: PowerBuilder to Java
• Pro: t
P ostensibly k
ibl keeps b i
business l i i t t
logic intact
• Makes for a great science project, reality can be disappointing
– Architectural issues, performance issues, security issues
• Depending on amount of business logic, you may be better off
rewriting
21

Remediate via Rewrite
22

Remediate via Rewrite
• Use the original application as the specification
– Minimizes the riskiest part of an application development project (requirements)
– Use both source code and a running application – static and dynamic
– Relies heavily on communication with users
• Provides greatest opportunity for a truly “modern” application
• Get the most benefit from security, quality and maintainability tools
security
– Much easier to use from the outset of a project than to bolt on later
• How much business logic has to be rewritten?
– What do you lose during the rewrite? Depends on type of software
– Line of business applications often less challenging than system software
23

Remediation Strategy
• Execution is key
– Clearly communicate goals, standards and priorities
• Beware bottlenecks
B b ttl k
– User acceptance testing
– Actual deployment into data center
• Data generation – where does test data come from?
• Data migration early for legacy data
– Do not want to be surprised later
24

Questions
25

For More Information
Denim Group John Dickson, CISSP
DIR Contract: DIR-SDD-660 john@denimgroup.com
(210) 572 4400
572-4400 @johnbdickson
@j h bdi k
Web: www.denimgroup.com
Blog: denimgroup.typepad.com Dan Cornell
dan@denimgroup.com
d @d i
@danielcornell
Gregory Genung
G G
ggenung@denimgroup.com
@ggenung
26