Designing your applications with a security twist 2007
Upcoming SlideShare
Loading in...5
×
 

Designing your applications with a security twist 2007

on

  • 1,647 views

Dave Read, Blue Slate CTO, shares his strategies for ensuring secure and compliant applications and systems.

Dave Read, Blue Slate CTO, shares his strategies for ensuring secure and compliant applications and systems.

Statistics

Views

Total Views
1,647
Views on SlideShare
1,607
Embed Views
40

Actions

Likes
1
Downloads
13
Comments
0

2 Embeds 40

http://www.techgig.com 36
http://www.techgig.timesjobs.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Designing your applications with a security twist 2007 Designing your applications with a security twist 2007 Presentation Transcript

  • Designing Your A li i D i i Y Applications with a Security Twist y David S. Read, Chief Technologist , g © 2007 Property Casualty Insurers Association of America
  • Contents o e s Application Security Landscape Security Standards and Best Practices Embedding Security in the SDLC Deep Di i t K E l it D Dive into Key Exploits © 2007 Property Casualty Insurers Association of America
  • We have entered a third phase in the i th world of IT security ld f it Phase 1 Phase 2 Phase 3 Software Application Internet Operating System S © 2007 Property Casualty Insurers Association of America
  • Addressing application security is now essential Server Application pp Non-Server Application 3% 2% 2% 1% 0% Operating System 15% 41% Hardware Communication Protocol Other 36% Network Protocol Stack Network security issues have Encryption Module attracted most attention The application layer has been left exposed and vulnerable © 2007 Property Casualty Insurers Association of America
  • Data shows that application security is a widespread i it i id d issue 75% 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 Pescatore Four 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 of hacker attacks - WebCohort's Application Defense Center In as study to determine the frequency in which a worm or virus was 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 flaws yp Trust of Client State Trust of Client Input Incomplete Instrumentation (Logging) Exploitable Designs Unencrypted Communications Weak Config Mgmt (e g Long-lived Accounts) (e.g. Long lived Backdoors Lack of Testing (Bugs Buffer Overflows, Race Conditions, etc.) Conditions etc ) © 2007 Property Casualty Insurers Association of America
  • Know the root causes by de- webbing th OWASP Top 10 bbi the T 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 Session Exploitable Designs, Unencrypted Communications, Trust of Client State, Backdoors Mgmt Cross Site Scripting (XSS) Trust of Client Input Flaws Buffer Overflows Lack of Testing, Trust of Client Input g 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 g Weak Configuration Mgmt, Incomplete Instrumentation, Lack of Testing, Backdoors Source: http://www.owasp.org/documentation/topten.html © 2007 Property Casualty Insurers Association of America
  • Contents o e s Application Security Landscape Security Standards and Best Practices Embedding Security in the SDLC Deep Dive into Key Exploits © 2007 Property Casualty Insurers Association of America
  • Why talk about security standards? Security failure may result in: – Unauthorized disclosure – Intentional or accidental loss, destruction, or modification of key information – T Temporary or extended lack of system availability t d dl k f t il bilit – Costs related with penalties, fines and repairs The goals of security are Prevention, Detection and Recovery – Prevent 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 repairs The foundation of having auditable and secure systems are effective security standards and policies – The standards must cover the entire application lifecycle – Th policies must b conspicuous and consistently enforced The li i t be i d i t tl f d © 2007 Property Casualty Insurers Association of America
  • Typical standards for application security Integrated Security Infrastructure Audit Trails Universal Participation Segregation of Duties S f Failsafe Stance (failure of security infrastructure, application access denied) Weakest Link (fix all weaknesses) Least Privilege Limit 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 flaws Should have security standards that define how security-related issues are to be documented and handled across the SDLC Should be based on current best practices, adjusted practices for specific data sensitivity issues Must be reviewed frequently to ensure that standards are being consistently enforced and met Audit trails must be monitored, manually or via scripts, so that abuse warning signs are spotted quickly Strong Passwords! © 2007 Property Casualty Insurers Association of America
  • From standards, principles for best practices emerge… emerge Security in Depth Segregation of Duties Identify Weakest Links Least Privilege Audit Trails Appropriate Communications Effective Configuration Management Paranoid Design © 2007 Property Casualty Insurers Association of America
  • Some key best practices for application security Application Control Checklist Multi-level Security Design and Code Reviews Third-party Audits Extended Testing Users – The Ultimate Firewall © 2007 Property Casualty Insurers Association of America
  • Application Control Checklist pp Project Management and Control Standards Application Systems Development Application Program Development Operating System Maintenance Program Maintenance Testing Documentation Implementation I l t ti Vendor Software/Support Source: http://www.auditnet.org/docs/ITGeneralControlsAudit.pdf © 2007 Property Casualty Insurers Association of America
  • Multi-level Security y AKA Security In Depth Don’t rely on a single point of enforcement – If a cracker gets past one level, hopefully the next will stop him/her Still need firewalls, IPSs, VPNs, DMZs, etc. – Just don’t rely on them to protect poorly designed or implemented software p Some exploits have nothing to do with software you control-how do you control these? – Social Engineering g g – WiPhishing – Physical Security © 2007 Property Casualty Insurers Association of America
  • Design and Code Reviews g Look for potential weaknesses in design and implementation Ensure company security standards are applied Use design patterns Use best practice security implementations – Don’t create your own in each application Simplify Si lif AOP 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 audits p y Fresh point, alternative to “group think” point group think Security 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 Audits are useful throughout the SDLC – Functional specifications – Design documents – Code reviews – Testing reviews – Audit trail reviews © 2007 Property Casualty Insurers Association of America
  • Extended Testing g Focus 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’t Unit Testing – Helps 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 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 vulnerability presented Random Testing – Focused on causing an unexpected or unhandled error – Critical, yet not expected ,y p © 2007 Property Casualty Insurers Association of America
  • Users – The Ultimate Firewall Users are the first and last line of defense of our data Training and consistent messaging are vital g g g to keep users aware of their role in following the corporate policies and practices designed to protect the business’ IT assets business Look for opportunities to help users protect system data y Establish and maintain a culture of security © 2007 Property Casualty Insurers Association of America
  • Use best practices to inform and i d improve standards t d d Think about security from the start … avoid costly y y repairs due to inadequate planning and design Identify security risks early and use FMEA to p prioritize and categorize the various levels of risk g Stay on top of statutory requirements and company policy on security Involve key constituents throughout the project life cycle to ensure all business requirements are captured Implement IT support for p p pp post-production monitoring p g and support © 2007 Property Casualty Insurers Association of America
  • Contents o e s Application Security Landscape Security Standards and Best Practices Embedding Security in the SDLC Deep Dive into Key Exploits © 2007 Property Casualty Insurers Association of America
  • Functional objectives drive security th it throughout the SDLC h t th Build / Deploy / Define D fi Analyze A l Design D i Test Support Application development life cycle segregated into distinct phases Security must be planned for and executed within every phase from inception Better to invest in security in the y development life cycle rather than pay heavily for security breaches in production © 2007 Property Casualty Insurers Association of America
  • Security (too) should start in the D fi th Define stage t Define Functional Objectives Security Considerations Identify project scope Understand company and success criteria policy regarding application security Establish core team requirements Produce a project Agree on security charter definitions and goals Classify security levels Select appropriate PM methodology © 2007 Property Casualty Insurers Association of America
  • Security standards must be established early t bli h d l 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 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 stakeholders t k h ld © 2007 Property Casualty Insurers Association of America
  • Security threats are specified in the A l th Analyze stage t Analyze Functional Objectives Security Considerations Benchmark existing Identify potential threats to business process (As Is) the application and build high level future Application A li ti security risk it i k process (To Be) categorization Perform gap analysis Evaluate the risks and Document business develop a requirements protection/security plan Identify risks inherent in the Identify training for key p process and establish risk constituents mitigation plan Use method for harvesting security requirements © 2007 Property Casualty Insurers Association of America
  • Standards during the Analyze stage t 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 y y possible attacks Design Functional Objectives Security Considerations Conversion of functional Integration of security into requirements into technical functionality during design specifications is easier and cheaper Design system with Rollback to gap analysis to potential security violation ensure all requirements are in mind (refer to FMEA) addressed Perform security design Obtain key constituent reviews to assure that signoff before proceeding security requirements are to development attained © 2007 Property Casualty Insurers Association of America
  • Standards are established and used 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 design documentation – User authentication routines and system access procedures (Segregation of D ties Least Pri ilege Weak Duties, Privilege, Configuration Management) – Information encryption (Unencrypted Communications) – Logging features to facilitate troubleshooting and ensure auditing capabilities (Audit Trails) Eliminate or mitigate any design flaws p g y g prior to development (Weakest Link) © 2007 Property Casualty Insurers Association of America
  • During the Build / Test stage, the security focus must be on the code Build / Test Functional Objectives Security Considerations Conversion of technical At code level, focus on specifications into blocks of code implementation flaws* forming the desired system / app Perform code review Establish user access and allocate – Finding and removing all g g system / app responsibilities implementation fl i l t ti flaws i in source code does nothing to Develop use case scenarios to address architectural test the app’s functionality problems* Perform tests and capture results Build security test plans* Obtain user and key business – T ti standard and security Testing t d d d it constituent signoff for production functionality release – Risk-based testing based on attack patterns and threat models Consider cost-benefit when cost benefit designing / building security into your applications Source: From the Ground Up: The DIMACS Software Security Workshop, IEEE Computer Society, 2003 © 2007 Property Casualty Insurers Association of America
  • Security standards to establish and use in the Build / Test stage se B ild Build / Test 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) 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
  • During the Deploy / Support stage, security policies must be enforced Deploy / Support Functional Objectives Security Considerations Complete and publish all Registration approval and process and application login authorization in documentation place Conduct role-specific Enforce and maintain training plan for all security policy application users Continuously monitor y Develop an ongoing plan application against threats to ensure process and or attacks application control Implement application support for ongoing maintenance © 2007 Property Casualty Insurers Association of America
  • Standards are established and used in the Deploy / Support stage Deploy / Support Perform necessary training for new application Policy 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
  • Contents o e s Application Security Landscape Security Standards and Best Practices Embedding Security in the SDLC Deep Dive into Key Exploits © 2007 Property Casualty Insurers Association of America
  • Results of attacks can be extremely harmful t l h f l Stolen, lost, Stolen lost or improperly altered data Loss of system availability or Denial of Service S i Can cost the company dearly, in terms of worker productivity and unrecoverable customer goodwill May lead to lawsuits and lost revenue © 2007 Property Casualty Insurers Association of America
  • Types of Hackers and Common E l it C Exploits 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 Traversal ec o y es Definition –C Convinces th server t provide th client with a li ti of di t i the to id the li t ith listing f directory contents –Rather than accessing a specific file Risks –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 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 htaccess © 2007 Property Casualty Insurers Association of America
  • Type 1 XSS ype Definition –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 Risks –The risks include theft of user credentials, data, email addresses and cookies. –Th risks can cause a user t misunderstand what server i actually The i k to i d t d h t is t ll 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 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 content on a later screen. t t l t © 2007 Property Casualty Insurers Association of America
  • Type 2 XSS ype Definition –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 Risks –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 an code, attacker, is essentially embedded in the application. Root Cause –Type 2 XSS vulnerabilities are typically produced by developers. –Th normal use case i The l involves accepting i l ti input f t from a user th t i th 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. application © 2007 Property Casualty Insurers Association of America
  • SQL Injection Q jec o Definition –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 Risks –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. Root Cause R tC –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 Mitigation Live Demo Miti ti – Li D © 2007 Property Casualty Insurers Association of America