Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Application Security Review 5 Dec 09 Final


Published on

An Overview to Application Security

Published in: Education
  • Be the first to comment

Application Security Review 5 Dec 09 Final

  1. 1. Application Security Review Presented by Manoj Agarwal CEP on Dec 5, 09@IIA-India, Bombay Chapter
  2. 2. Agenda <ul><li>What is an Application Security Review </li></ul><ul><li>Why Application Security Assessment </li></ul><ul><li>Examples of Potential Vulnerabilities </li></ul><ul><li>Q & A </li></ul>
  3. 3. Reviewing Application <ul><li>Confidentiality </li></ul><ul><ul><li>Confidential information must only be divulged as appropriate, and must be protected from unauthorized disclosure or interception. </li></ul></ul><ul><ul><li>Confidentiality includes privacy considerations. </li></ul></ul><ul><li>Such disclosure can take place by word of mouth, by printing, copying, e-mailing or creating documents and other data etc. </li></ul><ul><li>Integrity </li></ul><ul><ul><li>Information integrity refers to the state of data as being correct and complete. This specifically includes the reliability of financial processing and reporting. </li></ul></ul><ul><ul><li>The integrity of data is not only whether the data is 'correct', but whether it can be trusted and relied upon </li></ul></ul><ul><li>Availability </li></ul><ul><ul><li>Information must be available to the business, its customers, and partners when, where, and in the manner needed. </li></ul></ul><ul><ul><li>Availability includes the ability to recover from losses, disruption, or corruption of data and IT services, as well as from a major disaster where the information was located. </li></ul></ul>
  4. 4. Motivation For Application Security <ul><li>Cost of recovery and lost productivity </li></ul><ul><li>Loss of data </li></ul><ul><li>Impact on consumer confidence </li></ul><ul><li>Legal risks </li></ul>
  5. 5. Security Principles <ul><li>Confidentiality </li></ul><ul><li>Integrity </li></ul><ul><li>Authentication </li></ul><ul><li>Authorization </li></ul><ul><li>Availability </li></ul><ul><li>Non-repudiation </li></ul>
  6. 6. Managing Risk <ul><li>Strategic </li></ul><ul><li>Tactical </li></ul><ul><li>Operational </li></ul><ul><li>Legal </li></ul>
  7. 7. Assessment Criteria <ul><li>Definition of an application </li></ul><ul><li>Scope of assessments </li></ul><ul><ul><li>High-risk </li></ul></ul><ul><ul><li>Medium-risk </li></ul></ul><ul><ul><li>Low-risk </li></ul></ul><ul><li>Types of Assessments </li></ul><ul><ul><li>Limited assessments </li></ul></ul><ul><ul><li>Comprehensive assessments </li></ul></ul>
  8. 8. Participants <ul><li>Security Policy </li></ul><ul><li>Threat Modeling </li></ul>Corporate Security Application Review Team Operations IT <ul><li>Risk Assessment </li></ul><ul><li>Audits </li></ul><ul><li>Action on Audit Findings </li></ul><ul><li>Action on Audit Findings </li></ul>Business Unit IT Groups
  9. 9. Application Security Process Framework Verify In Production Applications Design, Develop, Test, and Verify Secure Apps Educate IT Professionals Maintain and Publish Policies and Guidelines Respond to Security Exposure Incidents Apply Lessons Learned
  10. 10. Application Management – Secure Infrastructure NETWORK HOST APPLICATION ACCOUNT TRUST <ul><li>Architecture </li></ul><ul><li>Transport </li></ul><ul><li>Network device </li></ul><ul><li>Access control list (ACL) permission settings </li></ul><ul><li>Operating system </li></ul><ul><li>Services </li></ul><ul><ul><li>Internet Information Services (IIS) </li></ul></ul><ul><ul><li>Simple Mail Transfer Protocol (SMTP) </li></ul></ul><ul><ul><li>File Transfer Protocol (FTP) </li></ul></ul><ul><ul><li>NetBIOS/Remote procedure call (RPC) </li></ul></ul><ul><ul><li>Terminal Services </li></ul></ul><ul><li>Microsoft SQL Server TM </li></ul><ul><li>Input validation </li></ul><ul><li>Clear text protocol </li></ul><ul><li>Authentication </li></ul><ul><li>Authorization </li></ul><ul><li>Cryptography </li></ul><ul><li>Auditing and logging </li></ul><ul><li>Unused accounts </li></ul><ul><li>Weak or blank passwords </li></ul><ul><li>Shared accounts </li></ul><ul><li>Access privileges </li></ul><ul><li>Rogue trusts </li></ul>
  11. 11. Building Secure Networks – Configuration <ul><li>Network segmentation </li></ul><ul><li>Firewalls </li></ul><ul><li>Routers and switches </li></ul>
  12. 12. Building Secure Networks – Intrusion Detections Systems And Network Encryption <ul><li>Detection systems should monitor for </li></ul><ul><ul><li>Reconnaissance attacks </li></ul></ul><ul><ul><li>Exploit attacks </li></ul></ul><ul><ul><li>Denial of service attacks </li></ul></ul><ul><li>Network encryption </li></ul><ul><ul><li>Key tool in preventing sensitive data from being read </li></ul></ul><ul><ul><li>Sensitive communication should be encrypted </li></ul></ul><ul><ul><li>Industry-standard encryption methods: Secure Sockets Layer (SSL), secure shell program such as SSH, Internet Protocol Security (IPSec) </li></ul></ul>
  13. 13. Building Secure Hosts For Applications <ul><li>Patch management </li></ul><ul><li>Configuration </li></ul><ul><li>Permissions </li></ul><ul><li>Simple Network Management Protocol community strings </li></ul><ul><li>Antivirus software </li></ul><ul><li>Server auditing and logging </li></ul><ul><li>Server backup and restore </li></ul>
  14. 14. Application Layer Requirements <ul><li>Input validation </li></ul><ul><li>Session management </li></ul><ul><li>Authentication and authorization </li></ul><ul><li>Design and code review </li></ul><ul><li>Application and server error handling </li></ul><ul><li>Application auditing and logging </li></ul><ul><li>Application backup and restore </li></ul><ul><li>Private data encryption </li></ul>
  15. 15. Common Application Development Issues <ul><li>User input validation </li></ul><ul><li>Cookies, authentication, and access </li></ul><ul><li>Passwords </li></ul><ul><li>Access control lists </li></ul><ul><li>Auditing and logging </li></ul>
  16. 16. Lessons Learned <ul><li>If you wait until an application is already in production to make it secure, you are too late </li></ul><ul><li>Good security practices take into account both the host and the application client </li></ul><ul><li>Create clearly written and easily accessible security guideline documentation </li></ul><ul><li>Create security checklists that include step-by-step instructions </li></ul><ul><li>Develop a thoroughly considered policy exception tracking process </li></ul><ul><li>Education is crucial to the success of a security program </li></ul><ul><li>Processes and reporting are required to ensure that inventory information is maintained </li></ul><ul><li>Security is an ongoing, always changing, concern </li></ul>
  17. 17. Lessons Learnt.. <ul><li>70% of applications reviewed by security firms had significant security design flaws </li></ul><ul><li>Interaction between server, 3rd party code, and custom business logic creates vulnerabilities </li></ul><ul><li>Patching or rebuilding app expensive </li></ul><ul><li>Perception exists that locking down OS and web server = web security </li></ul><ul><li>Web-facing, business critical applications </li></ul><ul><li>HTTP & SLL open to the world </li></ul><ul><li>Much investment focused on infrastructure </li></ul><ul><li>Well understood threats, mature products </li></ul><ul><li>Firewalls, authentication, intrusion detection </li></ul><ul><li>Security many times an overlooked facet of web development projects </li></ul>
  18. 18. Policies <ul><li>Applications should comply with application security policies and guidelines </li></ul><ul><li>Applications should go through a security design review process </li></ul><ul><li>Third-party application vendors should provide assurances that the software does not contain anything that could be used to compromise security controls </li></ul><ul><li>Internet-facing applications should use existing methods of authentication </li></ul><ul><li>Applications that reside on the corporate network should rely on Windows integrated authentication </li></ul><ul><li>Applications that cannot use Windows integrated authentication should either encrypt or hash the password stores </li></ul><ul><li>Credentials should never be stored or sent unencrypted </li></ul><ul><li>User input should be filtered and examined at the Web server </li></ul><ul><li>Web applications should use strong, nonpredictable session IDs </li></ul><ul><li>Web applications should use an inactivity timeout </li></ul><ul><li>Cookies that contain sensitive data should be marked as secure and nonpersistent </li></ul>
  19. 19. Examples…Parameter Tampering <ul><li>Price information is stored in hidden HTML field with assigned $ value </li></ul><ul><li>Assumption: hidden field won’t be edited </li></ul><ul><li>Attacker edits $ value of product in HTML </li></ul><ul><li>Attacker submits altered web page with new “price” </li></ul><ul><li>Still widespread in many web stores </li></ul>
  20. 20. Examples…Cookie Poisoning <ul><li>Attacker impersonates another user </li></ul><ul><ul><li>Identifies cookie values that ID’s the customer to the site </li></ul></ul><ul><li>Attacker notices patterns in cookie values </li></ul><ul><ul><li>Edits pattern to mimic another user </li></ul></ul>
  21. 21. Un-validated Input Attack <ul><li>Exploitation of implied trust relations </li></ul><ul><li>Instead of: </li></ul><ul><ul><li>[email_address] </li></ul></ul><ul><li>Attacker inputs: </li></ul><ul><ul><li>////////////////////////////////////////////////// </li></ul></ul><ul><li>Exploits lack of boundary checkers on back-end application </li></ul>
  22. 23. <ul><li>Thank You </li></ul>