Presentation on theme: "Application Software Assurance Program (ASAP) Santosh S Kandala Technical Analyst Application Consulting & Engineering Anmol Malhotra."— Presentation transcript:
Application Software Assurance Program (ASAP) Santosh S Kandala Technical Analyst Application Consulting & Engineering santoshs@Microsoft.com Anmol Malhotra Technical Analyst Application Consulting & Engineering anmolm@Microsoft.com Ramshanker Krishnan Group Program Manager Application Consulting & Engineering ramshk@Microsoft.com
Sydney Chofu & Otemachi Les Ulis Thames Valley Park Dublin Benelux Madrid Dubai Singapore Johannesburg Sao Paulo 90,000 mailboxes Microsoft IT Environment Canyon Park, Redmond Las Colinas Charlotte Chicago Milan Stockholm Munich 400+ supported Microsoft sites worldwide 6-7M e-mail messages per day 300,000+ network devices 6,000 data-center servers 110 Exchange servers/36 mailbox servers Silicon Valley 400 primary LOB applications 26 million voice calls per month 55,000 employees
Enterprise Risk Model High Low High Impact to Business (Defined by Business Owner) Low Acceptable Risk Unacceptable Risk Probability of Exploit (Defined by Corporate Security) Risk assessment drives to acceptable risk Mission and Vision Operating Principles Risk Based Decision Model Tactical Prioritization
Components of Risk Assessment AssetThreat Impact VulnerabilityMitigation Probability + + = = What are you trying to assess? What are you afraid of happening? What is the impact to the business? How could the threat occur? What is currently reducing the risk? How likely is the threat given the controls? Current Level of Risk What is the probability that the threat will overcome controls to successfully exploit the vulnerability and affect the asset? Mission and Vision Operating Principles Risk Based Decision Model Tactical Prioritization
Motivation For Application Security Cost of recovery and lost productivity Loss of data Impact on consumer confidence Legal risks
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
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
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
ASAP Process Designed To Be Inline With SDLC Application Software Assurance Program Process: Typical Software Development Life Cycle:
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.
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
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 S poofing, T ampering, R epudiation, I nformation Disclosure, D enial of Service, E levation of Privilege –Threat rating D amage Potential, R eproducibility, E xploitability, A ffected Users, D iscoverability
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
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
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
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 vulnerability Code Snippet : http://www.yourapplicationname.com/home.aspx?name= alert(‘Your page is hacked’) 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.home.aspx.cs
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.
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 http://internalwebsite/Lists/vulnerability_type.aspx ------------------------------------------------------------------------------------------------- For information on the Escalations & Exceptions process, please see the following link: http://internalwebsite/aaa/default.aspx ================================================================
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
Useful Links IT Showcase: http://www.microsoft.com/itshowcase ASAP : http://www.microsoft.com/technet/itsolutions/msit/secur ity/applsa.mspx http://www.microsoft.com/technet/itsolutions/msit/secur ity/applsa.mspx Improving Web Application Security: Threats and Countermeasures http://msdn.microsoft.com/library/default.asp?url=/librar y/en-us/dnnetsec/html/ThreatCounter.asp http://msdn.microsoft.com/library/default.asp?url=/librar y/en-us/dnnetsec/html/ThreatCounter.asp
Your consent to our cookies if you continue to use this website.