Designing your applications with a security twist 2007

D i i Y A li iDesigning Your Applications with a Security Twisty

David S. Read, Chief Technologist, g

© 2007 Property Casualty Insurers Association of America

ContentsContentso e so e s

Application Security LandscapeSecurity Standards and Best PracticesSecurity Standards and Best PracticesEmbedding Security in the SDLCD Di i t K E l itDeep Dive into Key Exploits


We have entered a third phase i th ld f IT itWe have entered a third phase i th ld f IT itin the world of IT security in the world of IT security

Phase 1 Phase 2

Software

Phase 3

Internet

Application

Operating S

Internet

System


Addressing application security is now essentialAddressing application security is now essentialsecurity is now essentialsecurity is now essential

Server Application

3% 2% 2% 0%1%

pp

Non-Server Application

Operating System15% 41% Hardware

Communication Protocol

36%

Other

Network Protocol StackNetwork security issues have Encryption ModuleNetwork security issues have attracted most attentionThe application layer has been left exposed and vulnerable


left exposed and vulnerable

Data shows that application it i id d i

Data shows that application it i id d isecurity is a widespread issuesecurity is a widespread issue

75% of attacks against Web servers are entering through75% of attacks against Web servers are entering through applications and not at the network level. When a company makes even subtle changes on its Web sites and applications, new vulnerabilities can arise – Gartner’s John PescatoreFour years of penetration testing on more than 250 web applications including e-commerce, online banking, enterprise collaboration, and supply chain management sites showed that at least 92% of web applications are vulnerable to some form ofat least 92% of web applications are vulnerable to some form of hacker attacks - WebCohort's Application Defense CenterIn as study to determine the frequency in which a worm or virus was spread via email versus the Web, It was found that the Webwas spread via email versus the Web, It was found that the Web was responsible for 30% of infections and only 20-25% were caused by malicious emails – IDC Denmark


Typical software flawsTypical software flawsypyp

Trust of Client StateTrust of Client StateTrust of Client InputIncomplete Instrumentation (Logging)Exploitable DesignsUnencrypted CommunicationsWeak Config Mgmt (e g Long-lived Accounts)Weak Config Mgmt (e.g. Long lived Accounts)BackdoorsLack of Testing (Bugs Buffer Overflows, Race Conditions etc )Conditions, etc.)


Know the root causes by de-bbi th OWASP T 10

Know the root causes by de-bbi th OWASP T 10webbing the OWASP Top 10webbing the OWASP Top 10

OWASP Vulnerability Type of Flaw

Unvalidated Input Trust of Client Input

Broken Access Control Exploitable Designs, Incomplete Instrumentation, Lack of Testing, Backdoors

Broken Auth and SessionBroken Auth and Session Mgmt Exploitable Designs, Unencrypted Communications, Trust of Client State, Backdoors

Cross Site Scripting (XSS) Flaws Trust of Client Input

Buffer Overflows Lack of Testing, Trust of Client Inputg p

Injection Flaws Lack of Testing, Trust of Client Input

Improper Error Handling Exploitable Designs, Incomplete Instrumentation, Lack of Testing

Insecure Storage Unencrypted Communications, Exploitable Designs, Lack of Testing, Backdoors

Denial of Service Exploitable Designs

Insecure Conf Mgmt Weak Configuration Mgmt, Incomplete Instrumentation, Lack of Testing, Backdoors


gSource: http://www.owasp.org/documentation/topten.html


Application Security LandscapeSecurity Standards and Best PracticesSecurity Standards and Best PracticesEmbedding Security in the SDLCDeep Dive into Key Exploits


Why talk about security standards?Why talk about security standards?standards?standards?

Security failure may result in:Security failure may result in:– Unauthorized disclosure– Intentional or accidental loss, destruction, or modification of key

informationT t d d l k f t il bilit– Temporary or extended lack of system availability

– Costs related with penalties, fines and repairsThe goals of security are Prevention, Detection and Recovery– Prevent the breach of a security policyPrevent the breach of a security policy– Enable the detection of activities that are in violation of security

policy– Stop the security violation, identify the attacker, and provide

corrective action to assess damage and perform repairscorrective action to assess damage and perform repairsThe foundation of having auditable and secure systems are effective security standards and policies– The standards must cover the entire application lifecycle

Th li i t b i d i t tl f d


– The policies must be conspicuous and consistently enforced

Typical standards for application securityTypical standards for application securityapplication securityapplication security

Integrated Security InfrastructureIntegrated Security InfrastructureAudit TrailsUniversal ParticipationS fSegregation of DutiesFailsafe Stance (failure of security infrastructure, application access denied)Weakest Link (fix all weaknesses)Least PrivilegeLimit design/implementation knowledge for vendorsLimit design/implementation knowledge for vendors (need to know basis-compartmentalization)


Use standards as the basis for controls to mitigate flawsUse standards as the basis for controls to mitigate flawscontrols to mitigate flawscontrols to mitigate flaws

Should have security standards that define howShould have security standards that define how security-related issues are to be documented and handled across the SDLCShould be based on current best practices adjustedShould be based on current best practices, adjusted for specific data sensitivity issuesMust be reviewed frequently to ensure that standards are being consistently enforced and metare being consistently enforced and metAudit trails must be monitored, manually or via scripts, so that abuse warning signs are spotted quicklyquicklyStrong Passwords!


From standards, principles for best practices emergeFrom standards, principles for best practices emergebest practices emerge…best practices emerge…

Security in DepthSecurity in DepthSegregation of DutiesIdentify Weakest LinksIdentify Weakest LinksLeast PrivilegeAudit TrailsAppropriate CommunicationsEffective Configuration ManagementParanoid DesignParanoid Design


Some key best practices for application securitySome key best practices for application securityapplication securityapplication security

Application Control ChecklistApplication Control ChecklistMulti-level SecurityDesign and Code ReviewsDesign and Code ReviewsThird-party AuditsExtended TestingExtended TestingUsers – The Ultimate Firewall


Application Control Checklist Application Control Checklist pppp

Project Management and ControlProject Management and Control Standards Application Systems DevelopmentApplication Program DevelopmentOperating System Maintenance Program MaintenanceProgram Maintenance Testing Documentation I l t tiImplementation Vendor Software/Support


Source: http://www.auditnet.org/docs/ITGeneralControlsAudit.pdf

Multi-level SecurityMulti-level Securityyy

AKA Security In DepthAKA Security In DepthDon’t rely on a single point of enforcement– If a cracker gets past one level, hopefully the next will stop

him/herhim/herStill need firewalls, IPSs, VPNs, DMZs, etc.– Just don’t rely on them to protect poorly designed or

implemented softwarepSome exploits have nothing to do with software you control-how do you control these?– Social Engineeringg g– WiPhishing– Physical Security


Design and Code ReviewsDesign and Code Reviewsgg

Look for potential weaknesses in design andLook for potential weaknesses in design and implementationEnsure company security standards are appliedUse design patternsUse design patternsUse best practice security implementations– Don’t create your own in each application

Si lifSimplifyAOP can help with cross-cutting concerns such as logging and authorization– AOP modifies your source! Know your vendor!


Third-party auditsThird-party auditsp yp y

Fresh point alternative to “group think”Fresh point, alternative to group thinkSecurity experts have seen many situations and can generalize them to make your solutions more secure

Smaller shops can save cost by renting a security expert– Smaller shops can save cost by renting a security expertAudits are useful throughout the SDLC– Functional specifications

Design documents– Design documents– Code reviews– Testing reviews– Audit trail reviewsAudit trail reviews


Extended TestingExtended Testinggg

Focus is typically on UATFocus is typically on UAT– This assures the app does what the users need, it doesn’t help identify

whether the system will do things it shouldn’tUnit Testing

– Helps identify flaws quickly with minimal time spentHelps identify flaws quickly with minimal time spent– Gives developers a quick way to prove code is working– Exposes overly complex code, difficult to test with many dependencies– Should test all paths, particularly error handling code

Security TestingSecurity Testing– Based on the belief that the software is vulnerable, utilizes tests to exploit

those vulnerabilities– Once each vulnerability is found, it’s root cause must be identified and fixed– Standards should be updated to reflect any new knowledge the vulnerabilityStandards should be updated to reflect any new knowledge the vulnerability

presentedRandom Testing

– Focused on causing an unexpected or unhandled error– Critical, yet not expected


, y p

Users – The Ultimate FirewallUsers – The Ultimate Firewall

Users are the first and last line of defense ofUsers are the first and last line of defense of our dataTraining and consistent messaging are vital g g gto keep users aware of their role in following the corporate policies and practices designed to protect the business’ IT assetsto protect the business IT assetsLook for opportunities to help users protect system datayEstablish and maintain a culture of security


Use best practices to inform d i t d d

Use best practices to inform d i t d d

Think about security from the start … avoid costly

and improve standardsand improve standardsy y

repairs due to inadequate planning and designIdentify security risks early and use FMEA to prioritize and categorize the various levels of riskp gStay on top of statutory requirements and company policy on securityInvolve key constituents throughout the project lifeInvolve key constituents throughout the project life cycle to ensure all business requirements are capturedImplement IT support for post-production monitoring p pp p p gand support





Functional objectives drive it th h t th SDLC

Functional objectives drive it th h t th SDLC

D fi A l D i Build / Deploy /

security throughout the SDLCsecurity throughout the SDLC

Application development life cycle

Define Analyze Design Build / Test

Deploy /Support

Application development life cycle segregated into distinct phasesSecurity must be planned for and executedSecurity must be planned for and executed within every phase from inceptionBetter to invest in security in the ydevelopment life cycle rather than pay heavily for security breaches in production


Security (too) should start in th D fi tSecurity (too) should start in th D fi t

Functional Objectives Security Considerations

the Define stagethe Define stage Define

Identify project scope and success criteria

Understand company policy regarding


and success criteriaEstablish core team Produce a project

policy regarding application security requirementsAgree on securityProduce a project

charterAgree on security definitions and goalsClassify security levelsSelect appropriate PM methodology


Security standards must be t bli h d l

Security standards must be t bli h d l

Company policies to:

established earlyestablished early Define

Company policies to:– Ensure confidentiality, integrity, and availability of apps and info

(Security in Depth, Segregation of Duties, Unencrypted Communications)– Ensure the proper and authorized use of such applications andEnsure the proper and authorized use of such applications and

information (Security in Depth, Segregation of Duties, Least Privilege)– Provide for emergency recovery and restoration in case of attack or

failure (Security in Depth, Audit Trails, Exploitable Design)

Project management methodologies to:– Ensure proper resources are assigned and roles/responsibilities are

clearly understood– Require process and deliverable documentation throughout each

phase– Require rigorous review and approval by team and business

t k h ld


stakeholders

Security threats are specified in th A l tSecurity threats are specified in th A l t


the Analyze stagethe Analyze stage Analyze

Benchmark existing business process (As Is) and build high level future

Identify potential threats to the applicationA li ti it i k


and build high level future process (To Be)Perform gap analysisDocument business

Application security risk categorizationEvaluate the risks and develop aDocument business

requirementsIdentify risks inherent in the process and establish risk

develop a protection/security planIdentify training for key constituentsp

mitigation plan Use method for harvesting security requirements


Standards during the Analyze t

Standards during the Analyze t

Identify training for key constituents

stage stage Analyze

Identify training for key constituents– Security Analysts, Designers, Developers, QA,

End Users and the Application Maintenance team pp(all security risk categories)

Use a standard methodology for gathering and defining security requirements– Find-Gather-Validate-Translate


Design stage should present a unified security architecture and identify all Design stage should present a unified security architecture and identify all


y ypossible attacks

y ypossible attacks Design

Conversion of functional requirements into technical

Integration of security into functionality during design is easier and cheaper


specificationsRollback to gap analysis to ensure all requirements are

is easier and cheaperDesign system with potential security violation in mind (refer to FMEA)

addressedObtain key constituent signoff before proceeding

in mind (refer to FMEA)Perform security design reviews to assure that security requirements are

to development attained


Standards are established and used in the Design stageStandards are established and used in the Design stage

Formal design reviews and stakeholder signoffs to

used in the Design stageused in the Design stage Design

Formal design reviews and stakeholder signoffs to ensure security has been addressed in Design (Covers all security risk categories)Apply technical safeguards in the designApply technical safeguards in the design documentation– User authentication routines and system access

procedures (Segregation of D ties Least Pri ilege Weakprocedures (Segregation of Duties, Least Privilege, Weak Configuration Management)

– Information encryption (Unencrypted Communications)– Logging features to facilitate troubleshooting and

ensure auditing capabilities (Audit Trails)Eliminate or mitigate any design flaws prior to


g y g pdevelopment (Weakest Link)

During the Build / Test stage, the security focus must be on the codeDuring the Build / Test stage, the security focus must be on the code


security focus must be on the codesecurity focus must be on the code Build / Test

Conversion of technical specifications into blocks of code forming the desired system / appEstablish user access and allocate

At code level, focus on implementation flaws*Perform code review

– Finding and removing all i l t ti fl i


Establish user access and allocate system / app responsibilitiesDevelop use case scenarios to test the app’s functionalityPerform tests and capture results

g gimplementation flaws in source code does nothing to address architectural problems*

Build security test plans*T ti t d d d itObtain user and key business

constituent signoff for production release

– Testing standard and security functionality

– Risk-based testing based on attack patterns and threat models

Consider cost benefit whenConsider cost-benefit when designing / building security into your applications


Source: From the Ground Up: The DIMACS Software Security Workshop, IEEE Computer Society, 2003

Security standards to establish and se in the B ild / Test stage

Security standards to establish and se in the B ild / Test stage

Formal code reviews to obtain signoff and ensure

Build / Testuse in the Build / Test stageuse in the Build / Test stage

Formal code reviews to obtain signoff and ensure that there are no apparent flaws in the application (look for threats in all security risk categories)When using outside vendors for development, limit the amount of details given on a need-to-know basis (Exploitable Design, Security in Depth)(Exploitable Design, Security in Depth)Use formal testing and use case scenarios to test the application– Unit Testing, Security Testing, User Acceptance

Testing, and Random Testing (covers all security risk categories)


risk categories)

During the Deploy / Support stage, security policies must be enforcedDuring the Deploy / Support stage, security policies must be enforced


security policies must be enforcedsecurity policies must be enforced Deploy / Support

Complete and publish all process and application documentation

Registration approval and login authorization in place


documentationConduct role-specific training plan for all application users

placeEnforce and maintain security policyContinuously monitor

Develop an ongoing plan to ensure process and application controlImplement application

yapplication against threats or attacks

Implement application support for ongoing maintenance


Standards are established and used in the Deploy / Support stageStandards are established and used in the Deploy / Support stage

Perform necessary training for new

the Deploy / Support stagethe Deploy / Support stage Deploy / Support

Perform necessary training for new applicationPolicy on continuous monitoring of applicationPolicy on continuous monitoring of application log files to identify misuse, potential threats, and/or attacks (Audit Trails)( )Recovery and restoration policy in case of failure or fatal attacks (Security in Depth)





Results of attacks can be t l h f l

Results of attacks can be t l h f l

Stolen lost or improperly altered data

extremely harmfulextremely harmful

Stolen, lost, or improperly altered dataLoss of system availability or Denial of S iService Can cost the company dearly, in terms of worker productivity and unrecoverable customer goodwillMay lead to lawsuits and lost revenue


Types of Hackers and C E l itTypes of Hackers and C E l itCommon ExploitsCommon Exploits

Types of hackers:Types of hackers:– Black Hats

Whit H t– White Hats– Grey Hats

Common types of exploit:– Directory Traversal– Cross-site Scripting (XSS)– SQL Injection


Directory TraversalDirectory Traversalec o y e sec o y e s

DefinitionC i th t id th li t ith li ti f di t–Convinces the server to provide the client with a listing of directory contents

–Rather than accessing a specific fileRisks

–Allowing users to access functionality that their role would not normally allow

–Allowing theft of configuration details and providing a complete list of application resources

Root Cause–Directory traversal vulnerabilities are typically due to flaws in

- Server Configuration and Server Software–Developers have some ability to help mitigate the riskDevelopers have some ability to help mitigate the risk

- Provide a standard default page in every directory of the web application (e.g. index.html, index.jsp, index.do)

- Provide appropriate, if redundant, server-specific configuration information such as htaccess files for an Apache server


information such as .htaccess files for an Apache server

Type 1 XSSType 1 XSSypeypeDefinition

–Involves a vulnerable application and tricking a user to enter some–Involves a vulnerable application and tricking a user to enter some exploit code

–A vulnerable application is one that echoes the input back to the front-end, unsanitized

–The exploit code can be hidden in places like an IM or email link–The exploit code can be hidden in places like an IM or email linkRisks

–The risks include theft of user credentials, data, email addresses and cookies.Th i k t i d t d h t i t ll–The risks can cause a user to misunderstand what server is actually controlling their UI experience, tricking him or her into divulging personal information. Further the hosting application that allows the exploit becomes a participant in the attack.

Root CauseRoot Cause–Type 1 XSS vulnerabilities are typically produced by developers.–The normal use case involves:

- Accepting input from a user that is then used as part of the t t l t


content on a later screen.

Type 2 XSSType 2 XSSypeypeDefinition

–Involves an application that stores unsanitized input in a repository–Involves an application that stores unsanitized input in a repository where it will later be sent to a user

–Email systems, blogs, news feedback sites and applications that store “comments” or user entered text for later retrieval are likely candidates

RisksRisks–The risks include all the risks of a type 1 XSS, without the need to trick the user into passing the exploit code to the server.

–The risks are passed onto many users (large number depending on the popularity of the site) since the exploit code once uploaded by anpopularity of the site) since the exploit code, once uploaded by an attacker, is essentially embedded in the application.

Root Cause–Type 2 XSS vulnerabilities are typically produced by developers.Th l i l ti i t f th t i th–The normal use case involves accepting input from a user that is then stored intact in the application’s database.

–As with Type 1 XSS, by creating targeted input the attacker can cause the client application to send credentials destined for the application to a separate server and application


separate server and application.

SQL InjectionSQL InjectionQ jec oQ jec oDefinition

–Involves passing input from an application tier to the database–Involves passing input from an application tier to the database –Such that the input is treated as part of the SQL statement, not just as a parameter

RisksThe risks include allowing users to access any data that their database–The risks include allowing users to access any data that their database connection allows leading the theft, alteration and loss of data.

–Each of these risks can cause our application to provide misinformation or fail altogether.

R t CRoot Cause–SQL Injection vulnerabilities are typically produced by developers.–The normal use case involves accepting input from a user that is to be used as part of a SQL statement, often the where clause.

–Through careful manipulation of the input parameters the attacker learns what the template SQL statement looks like, what DBMS product is being used, what schemas, tables and columns can be accessed. Finally the attacker is able to extract the data from the backend.


SQL Injection Attack and Miti ti Li DSQL Injection Attack and Miti ti Li DMitigation – Live DemoMitigation – Live Demo


Technology

Designing your applications with a security twist 2007