Reducing Application Risk: minimizing your web application's attack surface


Published on

This webcast (now in PPT. format) demonstrates techniques to identify, reduce, and measure your application’s attack surface.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Security innovation is a company dedicated to helping our customers with hard application and data security problems. We’ve spent years researching security vulnerabilities, why they occur, what they look like in production code and how to find and fix them. We have experience working with some of the largest companies in a variety of industries - from software companies such as Microsoft to e-commerce companies such as amazon, financial companies and many more. We offer solutions for all phases of the SDLC including instructor led training, computer based eLearning courses, on-site consulting and security assessments as well as technology to help secure sensitive data over the network or at rest.
  • First let’s look at some common ways of measuring application security…
  • The attack surface is defined by the set of interfaces, or entry points, to the program. Attack surface reduction is the process of identifying and understanding all of the entry points that make up the attack surface and then reducing these to a minimum level. This is done by enumerating all of the interfaces, protocols, and code execution paths as well as understanding the trust levels required to access each entry point.For each entry point, you must consider the importance of the feature that it enables. For features that are not important to a vast majority of the users, turn the feature off, disable it by default, or don’t even install it by default; force your users to take explicit action to obtain that feature. As a result, any vulnerabilities related to that feature will affect a smaller percentage of your user base.Next, consider which types of users need that access to each feature, and then restrict its use to those classes. For example, don’t default to making the feature remotely accessible, allowing anonymous access, running with more privilege than is needed, etcA significant aspect of attack surface reduction is restricting who has access to a product feature and how they can obtain and use that access.
  • Keep in mind that attack surface reductionis not as simple as a binary switch – on or off. It’s the active management of how your software exposes its features and reducing that access to the minimum required to meet your specifications and usage scenarios. Without a conscious focus on this aspect of your software design and implementation you are guaranteed to have a larger attack surface than necessary and you are guaranteed to have a higher risk of an attacker exploiting your system.
  • Security Innovation can help you in your efforts to adopt a more secure development process or to otherwise improve the security of your applications. We offer a wide range of information and software security eLearning titles that cover topics such as how to adopt secure development processes, how to perform a penetration test, how to create more secure or java code and more. You can use these to help yourself, and your team, gain the skills to develop more secure applications.
  • Reducing Application Risk: minimizing your web application's attack surface

    1. 1. Reducing Application Risk:Minimizing your WebApplication’s Attack Surface Jason Taylor CTO Security Innovation
    2. 2. About Security Innovation• Software and Crypto Security Experts – 10+ years research on vulnerabilities and cryptography – Hundreds of assessments on world’s most dominant software applications• Products, Services & Training – Software & SDLC Assessments – Industry’s largest eLearning library – High-performance encryption• Helping organizations: – Build internal security awareness and expertise – Roll out secure software applications and products – Protect data in transit and while applications are accessing it
    3. 3. AgendaObjectives of Attack Surface Analysis and Reduction• Measuring and Reducing your Attack Surface• Microsoft Case Study• Conclusion
    4. 4. A Software Application’s Attack Surface• Software exposes key business and customer assets via entry points: – User interfaces – Web services – Direct database access – Network channels, pipes, files, APIs …• The entire collection of entry points in a product is called it’s Attack Surface – Set of ways in which adversaries can attack a software system – Not limited to local resources; channels used to communicate with remote resources are vectors for attack• Big Attack Surface = Big Security Work= Big Security Problems – With big attack surface, you must spend more time making sure the code is excellent quality, conservative, and defensive
    5. 5. Understanding Attack Surface• Attack Surface can Gauge Risk of Attack – Attack surface measures potential avenues of attack – Attack surface measures potential impact of an attack• Useful as a Metric in Design through Deployment – Measurement is both point-in-time and relative• Attacks over the years show that certain vectors are more likely to be opportunities of attack than others – Known (and un-patched) vulnerabilities – Services running with high privileges are more likely to cause damage when attacked – Files with full control (e.g., rwxrwxrwx) are more likely to be attacked than files with less generous permissions – Use of binary controls such as ActiveX or Flash increase the chance of a damaging attack
    6. 6. Main Goals of Attack Surface Reduction• Every feature that is added to an application adds risk• The aim for secure development is to reduce the overall risk by balancing functionality vs. risk – Reduce the amount of code executing by default – Reduce the volume of code that is accessible to untrusted users by default – Close doors (access points) that can be easily opened/exploited – Limit the damage if the access point is exploited Bottom Line: Fend off Future Attacks
    7. 7. Considerations for Attack Surface ReductionSome Web applications inherently need more attention onattack surface than others • Is it Internet or Intranet accessible? Internet implies more risk. • Does it transmit, store or manipulate sensitive data? – If so, there are potential threats to that data and depending on the data there may be regulatory compliance requirements. • Has the application had security problems in the past? – Past security problems increase the likelihood of future problems
    8. 8. Agenda• Objectives of Attack Surface Analysis and ReductionMeasuring and Reducing your Attack Surface• Microsoft Case Study• Conclusion
    9. 9. Common Metrics for Application Risk/Security• At CODE LEVEL – We count the number of bugs found – Not an ideal metric because: • It misses bugs that are not found (or fixed), perhaps the one that gets exploited • equal importance is given to all bugs, even though some bugs are easier to exploit than others • the exploit of one may result in more damage than the exploit of another• At the PRODUCT/SYSTEM level – We count the number of times a system version is mentioned in CERT, Microsoft Security Bulletins, MITRE CVEs, etc. – Not an ideal metric because it ignores the specific system configuration that gave rise to the vulnerability • whether a security patch has been installed • whether defaults are turned off • whether it always runs in system administrator mode.
    10. 10. New Metric to Add: Attack Surface• Rather than count bugs at code level or vulnerability reports at system level, you can measure the avenues of attack – The counts of these “more likely to be attacked” features determine a system’s attack surface• Attack Surface attempts to measure security in relative terms – Useful as a delta measurement (i.e. v1.2 to v1.n of a product) – Not useful for comparing app to app or as stand-alone metric
    11. 11. Measuring attack surface • Start with baseline, then measure each week – Define your minimal attack surface early on during design • If the attack surface count goes up, determine why and see if you can drive it back down – When engineers know you are measuring the attack surface, they may improve efforts Baseline Baseline + 1 month Comment3 x TCP ports 2 x TCP ports Good; one fewer port to worry about.1 x UDP port 2 x UDP port Which functionality opened the new UDP port? Why is it open by default? Is it authenticated? Is it restricted to a subnet?2 x Services (both 3 x Services (2 x SYSTEM, Why is another service running by default? Why areSYSTEM) 1 x LocalService) any running as SYSTEM?3 x ActiveX controls 4 x ActiveX controls Why is the new control installed? Is it safe for scripting?No additional user 1 x application account Turns out this is a member of the administrators groupaccounts too! Why? Whats the password?
    12. 12. Potential Uses for Attack Surface Measurement• Developers and architects can better prioritize testing efforts – If a software’s attack surface measurement is high, they may want to invest more in testing• Developers can use it as a guide while implementing patches of security vulnerabilities – A good patch should not only remove a vulnerability from a system, but also should not increase the systems attack surface.• Consumers can use it to guide their choice of configuration – Since a systems attack surface measurement is dependent on the systems configuration, software consumers would choose a configuration that results in a smaller attack surface exposure.• Risk Management/Corporate Security can understand their potential business exposure
    13. 13. Attack Surface & Entry Points• To attack an application, attackers will – Identify entry points – Exploit the entry point or the backend exposed behind it – Try to deny legitimate users access to these entry points• In our software, we have to: – Understand the attack surface – Reduce it as much as possible – Test against it for exposed vulnerabilities• Mapping our Attack Surface – Architecture and design docs, code.. – But how many entry points are undocumented • Temporary files? Pipes? Network communication? Registry keys? Embeddable code?
    14. 14. The Attack Surface Reduction Process• Look at all of your entry points – User input (UI) – Programmatic input (Web Service APIs) – File reads – Database access• Rank them – Authenticated versus anonymous – Administrator only versus user – Network versus local Attack Surface Reduction is as important as trying to get the code right
    15. 15. It’s Not Just About Turning Stuff Off! Higher Attack Surface Lower Attack Surface Executing by default Off by default Open socket Closed socket Anonymous access Authenticated access Constantly on Intermittently on Admin access User access Internet access Local subnet access SYSTEM Not SYSTEM! Uniform defaults User-chosen settings Large code Small code Weak ACLs Strong ACLs
    16. 16. Reducing your Attack Surface – Best Practices• Reduce the amount of code running by default• Reduce access to entry points by untrusted users – restrict access to network endpoints used by your application to the local subnet or IP range – limit access to network endpoints using authentication.• Reduce privilege to limit damage potential – Sandbox running code – Give higher permissions for as short a period as possible – Pay attention to trust boundaries• Integrate with your SDLC
    17. 17. ASR Best PracticesReduce the Amount of Running Code• Apply the 80/20 rule – Ask yourself, "Do 80 percent of users/customers use this feature?“ – If the answer is no, then turn it off and make it easy to turn the feature back on• Services can’t be attacked if they are not running – All forms of dynamic Web content should be opt-in – If there is security defect in a service, this ensures that the only affected users are those actively running the service (versus all software users)• ASR is not just an "on or off" proposition – You can reduce attack surface by limiting who can access the code once it is running – This has an interesting side effect: many features are still usable, but are inaccessible by attackers (must have knowledge of access controls?)
    18. 18. ASR Best PracticesReduce access to entry points by untrusted users• Example: – By default, most Web sites are accessible to all users – If the Web server limited access only to trusted users, or users on a specific subnet, then fewer users could take advantage of the defect – This is good because the code works for those who require the functionality – Restrict access to network endpoints used by your application to the local subnet or IP range.• To reduce the number of users who can communicate with potentially vulnerable code, authenticate before they can access the code – Limit access to network endpoints using authentication. Simply validating the user reduces your components attack surface. – Most bad guys are unauthenticated. By raising the authentication bar a little you can eliminate a large population of potential attackers.
    19. 19. ASR Best PracticesReduce access to entry points by untrusted users• Pay attention to trust boundaries – Review the entire data flow from entry point to data store – Look for all the potential data flows, data stores, and processes that the code touches (code that an attacker can touch) – Determine what privilege is required to access that entry point – Can you raise the authorization bar?• Example: Code with only two network-facing entry points – One is anonymous and the other can only be accessed by administrators – Hacker is going to attack the code along the anonymous data path simply because they can • Not going to exercise the administrative code path because, if they can, then they are already an administrator (and your problems are only just starting)  As you review dataflow, look for anonymous threat paths. It may be prudent to raise the authorization bar on these paths
    20. 20. ASR Best PracticesReduce privilege to limit damage potential• Even if your code has vulnerabilities, and you don’t limit access to the code, you can still reduce the damage potential by operating the code with reduced privileges – remove any privileges not explicitly required by the application• Example: Dangerous Backup Privilege – Any process running under an account with this privilege can read any file in the file system, regardless of the access control list (ACL) on the file – Wrong way run as SYSTEM, which has backup privilege, but also has restore, debug, and "act as part of operating system" privilege; and is an admin account too – Right Way: run service under a specific authenticated account that has this privilege Never run services as SYSTEM, or daemons as root, or user accounts with administrative rights unless you have exhausted all other possibilities
    21. 21. ASR Best PracticesIntegrate with your SDLC• When designing your application, outline what the attack surface will look like and identify the following: – The networking protocols you enabled by default – The endpoints that should support authentication and authorization. Focus on other anonymous endpoints – The off-by-default features • Look for code that auto-starts or will execute when accessed, such as services, daemons, ISAPI filters and applications, SOAP services, and Web roots – Reusable components (ActiveX® controls, COM objects, and .NET Framework assemblies, etc) – Process identities for all the code you run – User accounts installed When developers know early what the attack surface looks like, they can design and code defensively from the start
    22. 22. ASR Best PracticesIntegrate into your SDLC• Implementation – Increase awareness of secure coding principles – Discover dangerous code changes that can add vulnerabilities or impact attack surface• Testing – Detailed measurement of attack surface – Test against attack surface specified during design• Deployment – Configuration changes can make a big impact on attack surface – Turn off features you’re not using, reduce privileges of running processes, etc
    23. 23. Agenda• Objectives of Attack Surface Analysis and Reduction• Measuring and Reducing your Attack SurfaceMicrosoft Case Study• Conclusion
    24. 24. Microsoft Attack Surface Reduction Case Study• In 2002, Michael Howard was asked to measure security progress in Windows Server 2003• He developed a set of metrics that became known as the Relative Attack Surface Quotient or “RASQ” • Open ports • Services running default • Named pipes • Services running as SYSTEM • RPC endpoints • IIS web directories (including sample apps) • Null Sessions • Users • Installed Services• Enumerating all these elements took about a dozen tools
    25. 25. Microsoft Attack Surface Reduction Case Study• RASQ for each version of Windows: NT4 through Windows XP
    26. 26. Microsoft Attack Surface Reduction Case StudyKey Deltas• NT4 SP6a + Option Pack to NT4 SP6a + Option Pack + IISChk – IISChk is a checklist which reduces attack surface• Windows 2000 + IISChk to Windows Server 2003 – Default install of Windows Server 2003 has smaller attack surface than Windows 2000 even after the checklist is applied
    27. 27. Microsoft Attack Surface Reduction Case StudyKey Takeaways• Windows Server 2003 – Watershed moment for Microsoft Windows – IIS no longer installed by default• As the SDL evolved, slogan emerged: Secure by Design, Secure by Default – First clause means “get the design and code secure” – Last clause means “product will never be 100% secure, so reduce its attack surface”• Microsoft teams saw the value of a reduced attack surface – Fewer security bulletins and lower severity bulletins – Attack surface analysis tool was born
    28. 28. Agenda• Objectives of Attack Surface Analysis and Reduction• Measuring and Reducing your Attack Surface• Microsoft Case StudyConclusion
    29. 29. Conclusion• Use Attack Surface Reduction to reduce your overall security profile – Protect against the threats and vulnerabilities you don’t know about• Match attack surface risk to the level of effort devoted to secure design, development and testing – Include Attack Surface analysis as part of your overall strategy – Include design, development and test best practices as effective ways to minimize your attack surface and overall risk• Get the Microsoft Attack Surface Analyzer Beta 9d6d-4bf4-aab8-f7352a5e7d45&displaylang=en
    30. 30. How Security Innovation can Help• Services – SDLC Process review – Code Review – Pen Test• eLearning Products – Computer based training – Secure Development Knowledgebase• Data Encryption – Fastest, most secure cryptography available on the market
    31. 31. eLearning Solutions for Secure Development Secure Development Knowledgebase – Out of the box secure development standards for: • Secure Design • Secure Coding • Security Testing – How-to’s, code snippets, attacks, checklistsComputer Based Training – Intro to Threat Modeling – OWASP Top Ten: Threats & Mitigations – Creating Secure ASP.Net & J2EE Code – Architecture Risk Analysis – Intro to Cryptography – 35 more
    32. 32. Free eLearning Course for Attending Introduction to Threat Modeling Creating Secure Code Fundamentals of Application Security Monthly Webcasts lab/upcomingwebcasts.shtml Contact