Upload
blue-slate-solutions
View
1.779
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Dave Read, Blue Slate CTO, shares his strategies for ensuring secure and compliant applications and systems.
Citation preview
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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.)
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
gSource: http://www.owasp.org/documentation/topten.html
ContentsContentso e so e s
Application Security LandscapeSecurity Standards and Best PracticesSecurity Standards and Best PracticesEmbedding Security in the SDLCDeep Dive into Key Exploits
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
– 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)
© 2007 Property Casualty Insurers Association of America
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!
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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!
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
, 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
© 2007 Property Casualty Insurers Association of America
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
© 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 SDLCDeep Dive into Key Exploits
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
Functional Objectives Security Considerations
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
stakeholders
Security threats are specified in th A l tSecurity threats are specified in th A l t
Functional Objectives Security Considerations
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
Functional Objectives Security Considerations
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
Design stage should present a unified security architecture and identify all Design stage should present a unified security architecture and identify all
Functional Objectives Security Considerations
y ypossible attacks
y ypossible attacks Design
Conversion of functional requirements into technical
Integration of security into functionality during design is easier and cheaper
Functional Objectives Security Considerations
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
Functional Objectives Security Considerations
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
Functional Objectives Security Considerations
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
© 2007 Property Casualty Insurers Association of America
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)
© 2007 Property Casualty Insurers Association of America
risk categories)
During the Deploy / Support stage, security policies must be enforcedDuring the Deploy / Support stage, security policies must be enforced
Functional Objectives Security Considerations
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
Functional Objectives Security Considerations
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
© 2007 Property Casualty Insurers Association of America
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)
© 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 SDLCDeep Dive into Key Exploits
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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
© 2007 Property Casualty Insurers Association of America
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.
© 2007 Property Casualty Insurers Association of America
SQL Injection Attack and Miti ti Li DSQL Injection Attack and Miti ti Li DMitigation – Live DemoMitigation – Live Demo
© 2007 Property Casualty Insurers Association of America