Web Application Security Roadmap Dr. Mohammad Iqbal Thanks to Joe White from Cyberlocksmith Co
Background • Web application security is still very much in it’s infancy. • Traditional ‘operations’ teams do not understand web application security risk and are ill-equipped to defend against web application threats. • Many companies are wrestling with web application security and assigning ownership of the entire web application security effort to one person but these companies are still trying to figure out where this person fits into the organization. • Security ‘turf battles’ are inevitable in these situations. • There is no clear separation between where web application security stops and traditional operations security begins.
Web Application Security Roadmap Objectives • Find Web Application vulnerabilities • Monitor/detect Web Application compromise attempts • Decide upon threat classification framework and scoring model Build a foundation • Address Web Application vulnerabilities • Develop Web Application Incident Response plan • Proactively increase security awareness • Threat Modeling (TM) and Data Flow Diagrams (DFDs) • Manual Code Review (outside expert) • Other possible Roadmap items to consider Internal projectsz ________________________ • Scope/prioritize internal Web Application specific projects
Find Web Application vulnerabilities • Automated component • Choose the automated web application security assessment tool that works best with your web application technology. • Make sure you are addressing all internet facing web application exposure. • Deploy Static Source code analysis tool to scan for security vulnerabilities within the source code. • Manual component • Manual web application security assessment is required to compliment the automated assessment above. • Work to better educate manual assessment teams of the way your web application functions so they can better detect logic flaws and other pieces likely to be missed by automated scans. • Integrate both peer code review and manual review of the static source code analysis results into your development life cycle. Build a foundation
Find Web Application vulnerabilities - 2 Web Application Security Assessment vendors • App. Scan - Watchfire (www. watchfire. com) • Core Impact - Core Security (www. coresecurity. com) • Hailstorm - Cenzic (www. cenzic. com) • NTOSpider - NT OBJECTives (www. ntobjectives. com) • Web. Inspect - SPI Dynamics (www. spydynamics. com) • White. Hat Sentinel - White. Hat Security (www. whitehatsec. com) Static Source Code Analysis vendors • Fortify - Fortify Software (www. fortifysoftware. com) • Ounce - Ounce Labs (www. ouncelabs. com) • Veracode – (www. veracode. com) Build a foundation
Find Web Application vulnerabilities - 3 Web Application Security assessment Cap. Ex and deployment times • 30 days to evaluate each vendor if conducting a bake-off • 0 -4 weeks to deploy chosen tool after the evaluation phase • Cap. Ex for web application security assessment tools will vary between vendors. Budget for 25 K - 50 K. Static Source Code Analysis Cap. Ex and implementation times • 30 days to evaluate each vendor if conducting a bake-off • 3 -6 weeks to deploy chosen tool after the evaluation phase • Cap. Ex for static source analysis tools will vary between vendors and will likley depend on the chosen deployment scenario as well as how many developers will be using the tool. One FTE should be expected to manage the tool, depending on the scale of environment. Budget for 50 K - 100 K (1 K - 3 K per developer). Build a foundation
Address Web Application vulnerabilities • Mitigate immediate internet facing risk • Block your exposure from web application vulnerabilities as close as possible to when they are discovered. THIS IS CRITICAL! • Buys you time to fix vulnerabilities in the underlying code. • Web Application Firewall (WAF) will minimize threat window for each exposure by blocking access to vulnerability until the vulnerability can be fixed in the code. • Address vulnerabilities in the code • Web application security assessment tool should assist in locating specific code level changes that need to be made • Static Source Code analysis will point directly to specific code level changes that need to be made • If possible, map your web application vulnerabilities directly to your bug tracking system. Build a foundation
Address Web Application vulnerabilities - 2 Web Application firewall (WAF) vendors • Web. Defend - Breach (www. breach. com) • Mod. Security - Open Source (www. modsecurity. org) support offered by Breach • Secure. Sphere - Imperva (www. imperva. com) • Application Security Manager - F 5 (www. f 5. com) • Citrix Application Firewall - Citrix (www. citrix. com) • Web Application Controller - Barracuda (www. barracudanetworks. com) Honorable mention • Fortify Real-Time Analysis (RTA) (Formerly called Fortify Defender) (www. fortifysoftware. com) Build a foundation
Address Web Application vulnerabilities - 3 Web Application Firewall Cap. Ex and deployment times • 30 days to evaluate each vendor if conducting a bake-off • 4 -8 weeks to deploy chosen tool after the evaluation phase • Ongoing management and fine-tuning can be expected after deployment • Cap. Ex for Web Application Firewalls will vary between vendors. Expect approx. 25 K-40 K per appliance and you will need at least two for redundancy. • Budget for 75 K-100 K Build a foundation
Detect Web Application compromise attempts • Deploy Web Application Firewall (WAF) Build a foundation
What is a Web Application Firewall? • Looks at Web Application (Layer 7) data and acts upon it. • Similar to a traditional network (Layer 4) firewall, …. • But not really a firewall after all • More like a gateway than a firewall, … • But not really like a gateway either Build a foundation
Where Web Application Firewall fits into traditional deployment architecture. Build a foundation
Traditional network layer security is blind to application layer threats Build a foundation
Web Application Firewall Use Cases (Ivan Ristic’s Blog, Mod. Security author) • Web intrusion detection and prevention • Continuous security assessment • Virtual (or just-in-time) patching • HTTP traffic logging and monitoring • Network building blocks • Web application hardening http: //www. modsecurity. org/blog/archives/2008/03/web_application_4. html Build a foundation
Detect Web Application compromise attempts • Deploy Web Application Firewall (WAF) • You cannot protect what you cannot see. Build a foundation
Detect Web Application compromise attempts • Deploy Web Application Firewall (WAF) • You cannot protect what you cannot see. http: //imgs. xkcd. com/comics/exploits_of_a_mom. png Build a foundation
Detect Web Application compromise attempts • Deploy Web Application Firewall (WAF) • You cannot protect what you cannot see. • You will need greater visibility into application layer traffic. • This is usually the piece that traditional operations security folks do not understand. • WAF should monitor and detect application anomalies and compromise attempts from users. • WAF offers greater visibility into application security events. • As WAF market matures, you can expect the WAF to be fed real-time vulnerabilities by your web application security assessment tool in order to proactively block newly discovered attacks. • The tricky part here is that you will likely need the help of the traditional operations security guys in order to successfully deploy your WAF into production environment. Build a foundation
Decide upon threat classification framework • Lots of framework options available to choose from. • Check out WASC and OWASP for more guidance here. • Should be consistent with the web application security assessment tool you have chosen • Whitehat Sentinel uses Web Application Security Consortium Threat Classification scheme (http: //www. webappsec. org/projects/threat/) • Authentication • Authorization • Client-side Attacks • Command Execution • Information Disclosure • Logical Attacks Build a foundation
Develop Web Application Incident Response plan • This is the piece overlooked by most organizations. • You do NOT want to be blind-sided by a web application security event while you are earning the trust of both your management and peers. • The operations security guys may actually want you to fail. • Expect a lot of policy writing and approx. 4 -8 weeks until total sign-off A web Application focused Incident Response plan will: 1. offer a predetermined course of action in the event of an Application Security incident. 2. allow for an expedited reaction to an application incident or occurrence. 3. leverage all tools/personnel available in a timely, effective and predetermined way. 4. Build confidence within your organization of your abilities. Build a foundation
Web Application Security Roadmap Objectives • Find Web Application vulnerabilities • Monitor/detect Web Application compromise attempts • Decide upon threat classification framework and scoring model Build a foundation • Address Web Application vulnerabilities • Develop Web Application Incident Response plan • Proactively increase security awareness • Threat Modeling (TM) and Data Flow Diagrams (DFDs) • Manual Code Review (outside expert) • Other possible Roadmap items to consider Internal projectsz ________________________ • Scope/prioritize internal Web Application specific projects
Scope/prioritize internal Web Application specific projects Ideally, you should try to build the general foundation for web application security as referenced in the prior slides before addressing the sample internal projects listed below. If necessary you can do them concurrently but understand that you will need to build a strong web application security foundation as soon as possible in order to be successful. • Integrate security into SDLC • Integrate security into QA process • Secured development lifecycle • Remote access to source code from offshore developers • Secure design review • Web Services / API architecture • Document coding standards • Integrate security into your application design process • Tighten up the platform framework Internal projects
Increase security awareness • Executive web application security risk awareness • Developer Training • Java black belt (http: //www. javablackbelt. com/) • Online development courses • Recurring Presentations/events • Security hack contests (hack-a-thon) • Secure development training • Strive to get everyone to start thinking like an attacker Internal projects
Threat Modeling and Data Flow Diagrams Threat Modeling • Understand all entry and exit points into the web application • Understand threat scenarios • Understand ‘trust boundaries’ in the application • Understand most likely data to be targeted by attackers • Know your ‘crown jewels’ Data Flow Diagrams • Understand anticipated user activity within the application flow • Understand expected data flow from one application component to the next Internal projects
Manual code review (outside expert) • Manual line-by-line code review for all application code by a Subject Matter Expert (SME) in your application technology. • Include all tiers in the application architecture: • client side within presentation tier • the application tier • the backend database tier • If budget restrictions require you to prioritize between tiers, address internet facing code first and then move on to application tier and then backend database tier. • Note: if presentation tier in your architecture can make database calls directly then you will need to review all code at the same time. • Cap. Ex should be budgeted at between 50 -100 K. A phased approach may spread the cost across multiple quarters/years. Internal projects
Other possible Roadmap items to consider • Distributed Denial of Service Attacks (DDo. S) • WAF should offer defense against Web Application Denial of Service (Do. S) attacks up to a point but it is not clear how much defense WAF will offer against a focused and coordinated DDo. S attack. • May require additional services from co-lo and/or upstream ISP. • Anti-Phishing • Companies/Services offer focused defense against targeted phishing and other attacks at your organization’s brand name. • These brand protection services are great to have in advance but can usually be ramped up quickly after targeted attacks are discovered. • Security Center • Reporting features of WAF should be available for users to increase security awareness and proactively address security weaknesses. • Web Application Security metrics Internal projects
Just remember this, … Information security risks and threats change over time. You must adapt to these changes. Web application security is the current threat that you need to understand be adapting to. If you are new to web application security, it is OK because there is still time to change and adapt. Don’t be an information security dinosaur!
Questions ? ? ? Latest version of this presentation: http: //www. webappsecroadmap. com
Скачать презентацию Web Application Security Roadmap Dr Mohammad Iqbal Thanks
c2bcf8261562545656027160c78d0e3c.ppt