1 / 28

Application Software Assurance Program (ASAP)

Inventory and assess line-of-business applications to identify and resolve security/privacy vulnerabilities, enabling strategic, tactical, operational, and legal application risk management.

chimalsi
Download Presentation

Application Software Assurance Program (ASAP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Application Software Assurance Program (ASAP) Ramshanker Krishnan Group Program Manager Application Consulting & Engineering ramshk@Microsoft.com Anmol Malhotra Technical Analyst Application Consulting & Engineering anmolm@Microsoft.com Santosh S Kandala Technical Analyst Application Consulting & Engineering santoshs@Microsoft.com

  2. Microsoft IT Environment 90,000 mailboxes 300,000+ network devices 6,000 data-center servers 110 Exchange servers/36 mailbox servers Stockholm Benelux Dublin Munich Thames Valley Park Chicago Canyon Park, Redmond Les Ulis Milan Chofu & Otemachi Madrid Silicon Valley Charlotte 400+ supported Microsoft sites worldwide Las Colinas Dubai Singapore 400 primary LOB applications 26 million voice calls per month 55,000 employees Sao Paulo Sydney Johannesburg 6-7M e-mail messages per day

  3. Mission and Vision Operating Principles Risk Based Decision Model Enterprise Risk Model Tactical Prioritization High Unacceptable Risk Risk assessment drives to acceptable risk Impact to Business (Defined by Business Owner) Acceptable Risk Low Low Probability of Exploit (Defined by Corporate Security) High

  4. Mission and Vision Operating Principles Risk Based Decision Model Components of Risk Assessment Tactical Prioritization Asset Threat Vulnerability Mitigation What are you trying toassess? What are you afraid of happening? How could the threat occur? What is currently reducing the risk? Impact Probability What is the impact to the business? How likely is the threat giventhe controls? + = Current Level of Risk What is the probability that the threat will overcome controls to successfully exploit the vulnerability and affect the asset?

  5. Motivation For Application Security • Cost of recovery and lost productivity • Loss of data • Impact on consumer confidence • Legal risks

  6. Purpose of ASAP • Inventory and assess line-of-business (LOB) applications • Identify and ensure resolution of security/privacy vulnerabilities found in those applications assessed. • Enable Application Risk Management: • Strategic • Tactical • Operational • Legal

  7. ASAP is Not Optional • All line-of-business application teams must go through ASAP • If they fail to do so, they cannot go into production • Enforcement of the ASAP process attributes to it’s success

  8. ASAP Program • ASAP should be thought of as both a set of standards, and as a process • Maintain and publish standards and guidelines that align with corporate policies • Educate IT professionals • Create threat models, conduct design reviews and code-level security and privacy assessments • Assess host-level security

  9. Program Participants CorporateSecurity Group ASAPTeam OperationsIT Group CorporatePrivacy/Lawand CorporateAffairs Group • Security policy • Impact assessment • Threat modeling • Limited and comprehensive assessments • Deploy and configure applications • Privacy policy Business Unit IT Groups • Action on assessment findings

  10. ASAP Process Designed To Be Inline With SDLC Typical Software Development Life Cycle: Application Software Assurance Program Process:

  11. Application Entry/Risk Assessment • Objective: • Application Inventory • Determine Application Risk Categorization • High Risk Security/Privacy Release • Medium Risk Security/Privacy Release • Low Risk Security/Privacy Release

  12. Parameters involved in evaluating risk • Audience • Type of users and volume • Data Classification • HBI,MBI,LBI and PII • Reliance / Integration • Dependency on other applications • Architecture • Internal/external facing etc.

  13. Application Risk Determines Service Level • High Risk Security Release • Compulsory threat model/design review plus white box code review and host level scan • Medium Risk Security Release • White box code review and host level scan • Low Risk Security Release • Host level scan

  14. Threat Model • Principle:Can’t build a secure system until you’ve identified all the threats against it. • Provide capability where teams can • Define – Information relevant to application security • Model – Threats, Attacks, Vulnerabilities and Mitigations • Measure – Impact, Probability, Cost, Benefit • Threat Categories • Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege • Threat rating • Damage Potential, Reproducibility, Exploitability, Affected Users, Discoverability

  15. Threat Modeling Tool – ACE Torpedo

  16. Application Principles • Confidentiality • Integrity • Authentication • Authorization • Availability • Non-repudiation

  17. Design Review • Objective: • Review and detect security vulnerabilities early in the development lifecycle. • Review application design to verify compliance with security standards and best practices. • Usually results in design changes. • Verify application meets application principles

  18. Pre-Production Assessment • Objective: • Low Risk Applications • Host Level Scan • Windows • IIS • SQL

  19. Pre-Production Assessment • Objective: • High/Medium Risk Applications • Host Level Scan • Windows • IIS • SQL • White Box Code Review

  20. White Box Code Review • Process • Application team provides source code • Analysts review application code uncovering security vulnerabilities • Vulnerabilities logged in bug database • Application team required to address all Sev 1 bugs prior to going into production

  21. Some common attack patterns white box review may reveal • Cross-Site Script Vulnerabilities • SQL Injection • Buffer Overflow • Poor Authorization Controls • Secrets Stored In Clear Text

  22. XSS Attack • Attacker normally exploits this by identifying the vulnerable page that outputs the invalidated input back to the browser. The following snippet of code shows the input that is accepted a vulnerable page that exploits this vulnerabilityCode Snippet :http://www.yourapplicationname.com/home.aspx?name=<script>alert(‘Your page is hacked’)</script>Code Snippet of home.aspx.cs :Response.Write(“Welcome” + Request.QueryString(“name”);When this link is clicked, it will show an alert message because of the script tag embedded in the url. The legitimate url is suppose to carry the original user name which can be exploited as above.

  23. SQL Injection • Following snippet of code shows how this vulnerability can be exploited. SqlDataAdapter myCommand = new SqlDataAdapter(“select * from tablename where fieldname = ‘” + userinput + “’”, myConnection);The above code gets executed based on the user input. This code can be exploited if the input is entered/passed as value’; Any valid SQL command.

  24. Sample Bug Template Issue : User controlled Input is displayed back to User without Validation and Encoding leading to Cross Site Scripting Vulnerability File: home.aspx.cs Code Snippet (Line No 102): Response.Write(“Welcome” + Request.QueryString(“name”); For a discussion of this vulnerability type & remediation steps, please see the following link: http://internalwebsite/Lists/vulnerability_type.aspx------------------------------------------------------------------------------------------------- For information on the Escalations & Exceptions process, please see the following link: http://internalwebsite/aaa/default.aspx ================================================================

  25. Post-Production Assessment • Objective: • High/Medium/Low Risk Applications • Host Level Scan • Windows • IIS • SQL

  26. Lessons Learned • If you wait until an application is already in production to make it secure, you are too late • Good security practices take into account both the host and the application client • Create clearly written and easily accessible security & privacy guidelines • Create checklists that include step-by-step instructions • Develop a thoroughly-considered policy exception tracking process • Education is crucial to the success of a security/privacy program • Security is an ongoing, always changing, concern

  27. Useful Links • IT Showcase: http://www.microsoft.com/itshowcase • ASAP : http://www.microsoft.com/technet/itsolutions/msit/security/applsa.mspx • Improving Web Application Security: Threats and Countermeasures http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/ThreatCounter.asp

  28. Thank You

More Related