Web Admin Blog

This presentation was by Jeff Williams, OWASP Chair, on the Enterprise Security API.

Vulnerabilities and Security Controls

• Missing – 35%
• Broken – 30%
• Ignored – 20%
• Misused – 15%

Goal is to enable developers.  Need to give them hands-on training, a secure coding guideline, and an Enterprise Security API.

The problem with Security Libraries: overpowerful, incomplete, not integrated, broken, can’t update, custom.

Enterprise Security API (ESAPI) includes authentication, user, AccessController, AccessReferenceMap, Validator, ENcoder, HTTPUtilities, Encryptor, EncryptedProperties, Randomizer, Exception Handling, Logger, IntrusionDetection, and SecurityConfiguration.  Built on top of your existing enterprise services or libraries.

Some Examples

1. Input Validation – validation engine and decoding engine that will take input and provide safe output for web pages
2. Output Encoding – need to use the right encoding for the right place you are putting the encoding
3. Authentication – creates a user object and functions to login() or logout().  Provides additional functionality for encrypted cookies, changing SESSIONID, remember me cookies, etc.
4. Access Control – provides functionality to check if a user is authorized for URLs, functions, data, services, or files.
5. Direct Object Reference Protection – use an access reference map that does an indirect translation between an object and it’s reference.  Use getDirectReference() and getIndirectReference() functions.
6. Error, Logging, and Detection – Configurable thresholds.  Responses are log intrusion, logout user, and disable account.  User object is available anywhere in the application so the logger links the messages logged to a user.  Exceptions sent to an intrusion detector which has thresholds set.

OWASP ESAPI Covers Majority of OWASP Top Ten

• A1. XSS – Validator, Encoder
• A2. Injection Flaws – Encoder
• A3. Malicious File Execution – HTTPUtilities (Safe Upload)
• A4. Insecure Direct Object Reference – AccessReferenceMap, AccessController
• A5. CSRF – User (CSRF TOken)
• A6. Leakage and Improper Error Handling – EnterpriseSecurityException, HTTPUtils
• A7. Broken Authenticationa nd Sessions – Authenticator, User, HTTPUtils
• A8. Insecure Cryptographic Storage – Encryptor
• A9. Insecure Communications – HTTPUtilities (Secure Cookie, Channel)
• A10. Failure to Restrict URL Access – AccessController

MITRE found that all application security tool vendors’ claims put together cover only 45% of the known vulnerability types (695).  They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true).  This means that at least 55% is not covered by tools.

Latest version released in September 2008 (1.3.1) and are holding a summit later this year to determine if they got everything right.  In active development.  Java, .NET, PHP, classic ASP.  Rich client extensions.  Web service extensions.  Framework (Struts) integration.

Written under the BSD license so it should be very easy for you to use it in your applciations.

Project Home Page: http://www.owasp.org/index.php/ESAPI

Expert advisory/design/implementation team that has collectively reviewed over 100 million lines of code.  ~600 JUnit test cases.  FindBugs, PMD, Ounce, and Fortify clean.  Code review by several Java security experts.  Penetration test of sample applications.  Full Javadoc for all functions.

Presentation will be posted on homepage.  Includes a list of banned API’s that ESAPI replaces.  Has example of enterprise cost savings.  All of ESAPI is only 5000 lines of code.  Building a ESAPI swingset which has a demo of insecure (what can go wrong) and secure (using ESAPI) programming and good tutorial on how to use.  Login module shows last successful login, last failed login, number of failed logins, enforces a strong password policy.

This presentation on the w3af (Web Application Attack and Audit Framework) was by Andres Riancho (ariancho@cybsec.com) who is the project leader.  w3af is an Open Source project (GPLv2).  A script that evolved into a serious project.  A vulnerability scanner.  An exploitation tool.  Found that the commercial tools were too pricey so developed a tool to make his job easier.

Finds almost all web application vulnerabilities.  Cross platform (written in python).  Uses tactical exploitation techniques to discover new URLs and vulnerabilities.  GTK and Console user interface.  Web service support.  Exploits [blind] SQL injections, OS commanding, remote file inclusions, local file inclusions, XSS, unsafe file uploads and more.  WML Support (WAP).  Really easy to extend.  Synergy among plugins.  Ability to find vulerabilities in query string, post data, URL filename, headers, file content (when uploading with forms) and web services.  130 plugins and growing.  Manual analysis web applications.

w3af is divided into two main parts, the core and the plugins.  The core coordinates the process and provides features that plugins consume.  Plugins share information with each other using a knowledge base.  Design patterns and objects everywhere!  8 different types of plugins exist:

• Discovery Plugins: Find new URLs and create the corresponding fuzzable requests (webSpider, urlFuzzer, googleSpider, pykto)
• Discover plugins are run in a loop, the output of one discovery plugin is sent as input to the next plugin.  This process continues until all plugins fail to find a new fuzzable request.
• Other discovery plugins try to fingerprint remote httpd, allowed HTTP methods, verify if the remote site has an HTTP load balancers.
• Audit Plugins: They take the output of discovery plugins and find vulnerabilities like [blind] SQL injection, XSS, buffer overflows
• Grep Plugins: These plugins grep every HTTP request and response to try to find information.  Examples are findComments, passwordProfiling, privateIP, directoryIndexing, getMails, and lang.
• Attack Plugins: These plugins read the vuln objects from the KB and try to exploit.
• Output Plugins: They write messages to the console, html or text file.
• Mangle Plugins: They modify requests and responses based on regexs
• Evasion Plugins: They modify the requests to try to evade IDS detection
• Bruteforce Plugins: They try to bruteforce logins

The presenter then demonstrated the w3af utility.  Very clean looking GUI similar to many of the linux GUI’s available.  Good use of tabs to separate various outputs.  I haven’t used it, but it looks fairly intuitive.  It has the ability to create exploit shells (OS, SQL, etc) just like I’ve seen with uber-expensive products like CoreImpact.  Ability to use python statements in HTTP requests to iterate through different pages. Some really useful graphing.

• archiveDotOrg plugin: Searches archive.org for older versions of the site, links that were linked somewhere in the past and now are kept in the dark.  Old and unmaintained sections are prone to vulnerabilities
• Use of PHP easter eggs to fingerprint the remote PHP version.  Old and almost forgotten technique.  Accurate fingerprinting.  Almost nobody disables the eggs (expose_php=off)
• Good samaritan module: A faster way to exploit blind SQL injections!  A funny way to exploit blind SQL injections!  “Guiding the blind man”
• Virtual Daemon: Ever dreamed about using metasploit payloads to exploit web applications?  Now you can do it!  Coded a metasploit plugin that connects to a virtual daemon and sends the payload.  The virtual daemon is run by a w3af attack plugin and receives the payload and creates a tiny ELF/PE executable.
• w3afAgent: A reverse “VPN” that allows you to continue intruding into the target network.  Send the w3afAgent client to the target host using a transfer handler (wget, tftp, echo).  The cient connects back to w3af where the w3afAgent server runs a SOCKS daemon. (Just like CoreImpact!!!  Freakin’ sweet!)  UDP traffic doesn’t work, but could.  Raw sockets, and sniffing won’t work.
• Web 2.0 Support.  w3af can analyze pages that make heavy use of JavaScript.  THe manual solution available to achieve this task is the spiderMan plugin.  Local proxy daemon.  Analyzes requests and creates fuzzable requests.  The user needs to navigate the JavaScript sections of the site.  Supports JSON.

Future

• Some level of javascript support (mozrepl)
• More stable core
• Less false positives/negatives
• More attack plugins
• Better GTK user interface
• Better management report generation
• Long descriptions for vulnerabilities using OWASP attack information from the wiki.

Site: http://w3af.sf.net

This presentation was by Yiannis Pavlosoglou who is the developer on the OWASP fuzzing project.

Address the challenges of fuzzing, during applicaton layer penetration tests and security assessments.  Designed for fuzzing web applications.  Open-source and free.  Written in Java.  Scriptable.

Fuzzer Workflow

• Select fuzzers
• Send requests
• Collect responses
• Compare results

Building a fuzzer entails a stable, ease to use interface, a solid fuzzing engine, and unconventional protocol APIs.

Likely Problems:

• How do you group payloads?
• How do you customize/iterate through permutations?
• Cannot use Apache HTTP Commons
• Cannot use Java HTTP/S Libraries

Addressing Problems:

• Graphical User Interface
• Write requests/responses to a file
• Payloads read from file
• Payloads grouped into fuzzers
• Fuzzers grouped into categories
• Use TCP Sockets for fuzzing
• Implement POST “Content-Length”
• Support SSL sockets for fuzzing
• Support HTTP/1.1 chunked encoding

47 classes spread into 13 packages.  13,123 lines of java code.  Do one thing and do it well!  Tell the user what you are putting on the wire.  Don’t obey HTTP/S.  Trust the JBroFuzz Core to generate payloads.

Roadmap

• MSI Installer
• Basic NTLM Authentication
• Proxy Requests
• Graphing Tab

E-mail yiannis@owasp.org with questions.

This talk was rumored to have been cancelled at a vulnerable vendors (Adobe) request, but Jeremiah Grossman and Robert Hansen decided to do parts of the talk anyway.  Here’s my notes from the semi-restricted presentation.

Jeremiah started off with a brief introduction on what clickjacking is.  In a nutshell, it’s when you visit a malicious website and the attacker is able to take control of the links that your browser visits.  The problem affects all of the different browsers except something like lynx.  The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you.  It’s a fundamental flaw with the way your browser works and cannot be fixed with a simple patch.  With this exploit, once you’re on the malicious web page, the bad guy can make you click on any link, any button, or anything on the page without you even seeing it happening.  “A normal user wouldn’t have any idea of what is going on.  People in this audience may see something a little different from what they would expect and you would definitely see the results in the page’s source code.”  Ebay, for example, would be vulnerable to this since you could embed javascript into the web page, although, javascript is not required to exploit this.  “It makes it easier in many ways, but you do not need it.”  Use lynx to protect yourself and don’t do dynamic anything.  You can “sort of” fill out forms and things like that.  The exploit requires DHTML.  Not letting yourself be framed (framebusting code) will prevent cross-domain clickjacking, but an attacker can still force you to click any links on their page.  Each click by the user equals a clickjacking click so something like a flash game is perfect bait. The issue and fix will probably be originally released on http://ihackcharities.org.

My Analysis: It sounds like the exploit basically creates a frame that is hidden underneath the main content frame that a user is seeing.  The main content could be a flash game or any sort of incentive to keep a user clicking.  All of the clicks that the user is making are used to click on content in the hidden frame. Again, just my speculation based on the information provided by RSnake and Jeremiah above.

Unfortunately, the conference provided lunch today, but did not provide us time to eat it so I had to eat while listening to this talk.  It was by Trey Ford and Jeremiah Grossman from Whitehat Security and I’m pretty sure they’ve done it before.  You may even be able to download a copy of the presentation off of http://www.whitehatsec.com.  The gist of the presentation is that while you can use a web application vulnerability scanner to find things like SQL injection or cross-site scripting, there are still a lot of very serious business logic flaws that won’t get caught by those tools.  A malicious person could exploit these business logic flaws for anything from helping a Chihuahua win a dog contest to making millions trading on insider information or running affiliate scams.  Some of the exploits presented were so easy that your mom could figure out how to do it and didn’t require ANY technical skills.  While the presentation may have not been technical enough for the majority of the people attending this conference, I still give props to Whitehat for putting together a decent presentation on how hackers are using business logic flaws to make money on the web.  Be sure to e-mail Whitehat and ask to see the presentation.

This presentation is by Christian Heinrich, the project leader for the OWASP “Google Hacking” project.  Presentation published on http://www.slideshare.net/cmlh  Dual licensed under OWASP License and AU Creative Commons 2.5.

OWASP Testing Guide v3 – Spiders/Robots/Crawlers

1. Automatically traverses hyperlinks

2. Recursively retrieves content referenced

Behavior governed by the robots exclusion protocol.  New method is <META NAME=”Googlebot” CONTENT=”nofollow”>  Not supported by all Robots/Spiders/Crawlers.  Traditional method is robots.txt located in web root directory.  Regular expressions supported by minority only.  “User-agent: *” applies to all spiders/robots/crawlers or you can specify a specific robot name.  Can be intentionally ignored.  Not for httpd access control or digital rights management.

Testing – Robots Exclusion Protocol

1. Sign into Google Webmaster Tools
2. On the dashboard, click the URL
3. Click “Tools”
4. Click “Analyze robots.txt”

Search Engine Discovery

Microsoft Remote Desktop Web Connection: intitle:Remote.Desktop.Web.Connection inurl: tsweb

VNC: “VNC Desktop” inurl:5800

Outlook Web Access: inurl:”exchange/logon.asp”

Outlook Web Access: intitle:”Microsoft Outlook Web Access – Logon”

Adobe Acrobat PDF: filetype:pdf

Google caught onto this and is now displaying a “We’re sorry” message with certain searches.  To get around, use different search queries that returns overlapping results.

Google Advanced Search Operators: “site:” and “cache:”  Two ways of using “site:”.  EIther as “site:www.google.com” where you get that specific subdomain’s results or “site:google.com” where you get all hostnames and subdomains. Use “cache:www.owasp.org” to display an indexed web page in the google cache.  There is also a site operator labeled “Cached” which will do the same thing.

You can get updates of the latest relevant Google results (web, news, etc) using Google Alerts.

Download Indexed Cache

Google SOAP Search API.  Query limited to either 10 words or 2048 bytes.  One thousand search queries per day and limited to search results within 0-999.  Up to 10K possible results from 10 different search queries.

$Google_SOA_Search_API -> doGoogleSearch( $key, $q, $start, $maxResults, $filter, $restricts, $safeSearch, $lr, $ie, $oe );

See presentation for response.

Proof of concept tool is “dic.pl” or “Download Indexed Cache” that downloads the search results.  Licensed under the Apache License 2.0.  Tool produces a URL and cachedSize response.

OWASP Google Hacking Project

Tools built using Perl using CPAN Modules SOAP::Lite, Net::Google, and Perl::Critic.  Development environmetn is based on Eclipse with EPIC Plug-in.  Subversion repository is at code.google.com.

Roadmap

Upcoming presentations at ToorCon X in San Diego, SecTor 2008 in Toronto, Canada, and RUXCON 2K8 in Sydney, Australia.

“TCP Input Text” Proof of Concept

“Speak English” Google Translate Workaround

Refactor and 3rd Project review of PoC Perl Code with public release at RUXCON 2K8 in November 2008.

Check in at code.google.com after RUXCON 2K8

4 hr “half day” training course Q1 2009

For the first session of the day, I decided to check out the Web Application Security Roadmap presentation by Joe White, President of Cyberlocksmith Corporation.  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 who takes ownership of web application security.  Still trying to figure out where they fit in the organization.  Security “turf battles” are inevitable in these situations.  No clear separation between where web app sec stops and traditional operation security begins.

Begin by building a foundation.  Find your web application vulnerabilities.  Address your web application vulnerabilities.  Monitor/detect web application compromise attempts.  Decide upon threat classification framework and scoring model.  Develop web application incident response plan.

Next, look at your internal projects.  Scope/prioritize internal web application specific projects.  Proactively increase security awareness.  Threat modeling and data flow diagrams.  Manual code review (outside expert).  Other possible roadmap items to consider.

To find web application vulnerabilities, there is an automated component and a manual component.  For the automated component, choose the automated assessment tool that works best with your web application technology.  Make sure you are addressing all internet facing web application exposure.  Deploy a static source code analysis tool to scan for security vulnerabilities within the source code.  The manual component is required to compliment the automated assessment.  You 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 the automated scans.  Integrate both peer code review and manual review of the static source code analysis results into your SDLC.

Web Application Security Assessment CapEx 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
• CapEx for web application security assessment tools will vary between vendors.  Budget for 25-50k

Static Source Code Analysis CapEx 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
• CapEx will vary between vendors and will likely depend on the chosen deployment scenario as well as how many developers are using hte tool.  Budget for 50-105k (1-3k per developer)

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.  WAF will minimize threat window for each exposure by blocking access to vulnerability until it can be fixed in the code.

Address the vulnerabilities in the code.  Web app sec 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.

WAF Vendors: Breach, ModSecurity, Imperva, F5, Citrix, Barracuda, Deny All, BeeWare, BinarySEC, Cisco, and Fortify Real-Time Analysis.

WAF Firewall CapEx 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
• CapEx varies between vendors.  Expect approximately 25-40k per appliance and need at least two for redundancy
• Budget for 75-100k (more for presence at multiple datacenters)

Check out wafreviews.com!  It’s a webappsec community supported site for information and resources related to WAF Reviews and Evaluations.  If you have participated in a recent bake-off of WAF technology and are able to share your results, feel free to forward your evaluation results to submit@wafreviews.com.  Mission is to be fair, objective, and comprehensive.

Detecting web application compromise attempts.  Use a WAF!  Looks at Web Application (Layer 7) data and acts upon it.  Similar to traditional network (Layer 4) firewall.  But more like a gateway than a firewall.  Likes to call it a “Web Application Risk Management (WARM)” device.  Device sits between your normal firewall and your web application server.

WAF Use Cases

• 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

Detect web application compromise attempts.  You cannot protect what you cannot see.  You will need greater visibility into application layer traffic.  This is usually the place 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 to help you implement and succeed.

Decide upon threat classification framework.

Develop a 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.

webappir.com  Seeking presentations and other educational material to assist web application security professionals.

Don’t let internal projects distract you from building the foundation!  Integrate security into the SDLC.  Secured development lifecycle.

Increase security awareness.  Executive web application security risk awareness.  Developer training.

Threat modeling and data flow diagrams.  Understand all entry and exit points into the web application.  Understand threat scenarios.

Manual code review (outside expert).  Include all tiers in the application architecture.  Address internet facing code first and then move on to application tier and then database tier.

Other roadmap items to consider.  DDoS attacks.  Anti-phishing.  Seecurity Center – reporting features of WAF should be available for users to increase security awareness and proactively address security weaknesses.  Web application security metrics.

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 and be adapting to.  If you are new, it is OK because there is still time to change and adapt.  Don’t be an information security dinosaur.  Latest version of the presentation available at http://www.webappsecroadmap.com

I’m currently at the OWASP AppSec 2008 Conference in New York City and am listening to the keynote presentation shared by the board of OWASP.  Starting off is Jeff Williams, Chair of OWASP.  He talked about OWASP’s mission, what we’re currently working on, and offered the following suggestions on how to take OWASP into the future:

1) Prioritize

• You can’t “hack” code secure.
• Use risk metrics.

2) Set a useful research agenda

• Don’t spend time searching for obscure vulnerabilities
• Create tools that verify that software does the RIGHT thing instead of just looking for problems.

3) Turn application security from a black art to a science

• OWASP in School program
• Translating OWASP Top 10 and various books and projects into other languages.
• Printing guides, books, and manuals for cost of printing.  Free downloads online.

4) We can enable secure coding

• Breaking things is easy, try creating something secure and tell people how you did it.
• Check out the OWASP Enterprise Security API Project
• Increased visibility (software should provide info on who built it, what libraries they used, etc)

5) Make application security into a movement

• Evangelize application security
• Show people what an application security program looks like

Next up was Dave Wichers.  He talked about the OWASP goals of improving quality and support.  OWASP is publishing a “desk reference” guide on application security.  Community outreach is a huge focus of OWASP.  Over 100 chapters around the world.  Dave is the Conference Chair and helps to organize these conferences.  Let him know if you’re interested in putting one on.

Tom Brennan, head of NY/NJ chapter and OWASP Board Member starts talking about over 10,000 members on the mailing list and over 120 chapters involved in OWASP effort.  Says you should get involved in OWASP!

Next up is Dinis Cruz, another board member, who says he comes up with all sorts of crazy ideas for OWASP.  Helped come up with the OWASP Grants ideas when the Belgium chapter had extra money in the bank.  OWASP Spring of Code 2007 sponsored 26 projects at $125,000.  Summor of Code 2008 has 31 grants and they are focusing on quality with reviewers, project managers, etc.  OWASP has given out over $250,000 in grants since the Seasons of Code project started.  Then he started talking about the OWASP EU Summit happening in Portugal in 2008 in November.  Nice hotel by the seafront.  Go to meet all of the guys who are influential in OWASP.  Coming up with a bunch of training courses that are completely OWASP related and mostly done by our leaders.  Lots of working sessions to start discussing projects and set the AppSec agenda for 2009.  Five nights at a 5 star hotel for 300 Euros if you share a room or 600 euros if you want a single.  It’s a deal!  If you’re at the conference, they’re giving out free books.

Last up is Sebastian Deleersnyder who compares OWASP to Second Life.  A lot of people doing this as a second job, but it’s also a virtual community.  Asks chapter leaders to stand up and everyone gives them a hand.  *pats self on the back*  End of keynote.

As I’m preparing to take my trip to New York for the OWASP AppSec Conference, I came across a timely article on the risks involved with using a hotel network.  The Center for Hospitality Research at Cornell University surveyed 147 hotels and then conducted on-site vulnerability testing at 50 of those hotels.  Approximately 20% of those hotels still run basic ethernet hub-type networks and almost 93% offer wireless.  Only six of the 39 hotels that had WiFi networks were using encryption (see my blog on why are people still using WEP for why this is necessary).  What does this mean for you, Joe User?  It means that both your personal and company information is at risk any time you connect to those networks.  The next time you’re surfing the web, start paying attention to all of the non-SSL links (http:// versus https://) that you visit.  Then, think about the information that you are passing along to those sites.  Are you signing in with a user name and password?  Entering credit card information?  Whatever it is, you better make sure that it’s something that you wouldn’t feel bad if it wound up on a billboard in Times Square, because that’s about how risky your trasmission could be.

Before you get too concerned, there are a few things you can do to try to prevent this.  First, DO NOT visit any links where you transmit information unencrypted.  This is just asking for trouble.  Since many man-in-the-middle type attacks can still be used to exploit this, my second suggestion is to use some sort of VPN tunnel.  Whether it’s a corporate VPN or just a freebie software VPN to your network back home, this allows you to encrypt all traffic over the untrusted hotel network.  Make this your standard operating procedure anytime you connect to an untrusted network (not just a hotel) and you should keep your data much safer.  Lastly, please be sure to have current firewall and anti-virus software on the computer you are using to connect to the untrusted network.  The last thing you want is to get infected by some worm or virus just by plugging in to the network.

One other thing that I think that deserves mentioning here is that if you don’t absolutely have to use the internet on an untrusted network, then don’t do it.  Obviously, there are times when you need access to do work, pay bills, etc, but if you can save those tasks until you reach a more familiar (and hopefully safer) network, that is far and away the best way to keep yourself and your data safe.

We’re trying to come to an agreement with a SaaS vendor about performance and availability service level agreements (SLAs).  I discussed this topic some in my previous “SaaS Headaches” post.  I thought it would be instructive to show people the standard kind of “defense in depth” that suppliers can have to protect against being held responsible for what they host for you.

We’ve been working on a deal with one specific supplier.  As part of it, they’ll be hosting some images for our site.  There’s a business team primarily responsible for evaluating their functionality etc., we’re just in the mix as the faithful watchdogs of performance and availability for our site.

Round 1 – “What are these SLAs you speak of?”  The vendor offers no SLA.  “Unacceptable,” we tell the project team.  They fret about having to worry about that along with the 100 other details of coming to an agreement with the supplier, but duly go back and squeeze them.  It takes a couple squeezes because the supplier likes to forget about this topic – send a list of five questions with one of them being “SLA,” you get four answers back, ignoring the SLA question.

Round 2 – “Oh, you said ‘SLA’!  Oh, sure, we have one of those.”  We read the SLA and it only commits to their main host being pingable.  Our service could be completely down, and it doesn’t speak to that.  Back to our project team, who now between the business users, procurement agent, and legal guy need more urging to lean on the supplier.  The supplier plays dumb for a while, and then…

[Read the rest of this entry…]