Web Admin Blog Real Web Admins. Real World Experience.


When an “Enterprise” Product Isn’t Enterprise Ready

I absolutely love my job and one of the coolest things about what I do is getting to do proof-of-concepts with bleeding edge technology.  I feel very privileged that many companies out there respect me enough to provide me with these opportunities and I feel that engaging on this level enables me to be a better security practitioner because I routinely have my finger on the pulse of the latest and greatest tools out there.  The problem that I run into, however, is when vendors present me "enterprise ready" tools that are clearly not enterprise ready.  Maybe it's a cool concept, a working prototype, or even a functional system.  The problem is that "enterprise ready" assumes so much more than just a product that does some stuff as advertised.  To me, at least, it assumes a product that can be easily transitioned to the company's IT team for long-term support of the platform.   Here are some signs to look out for that will tell you if the tool is truly ready for the big show:

  1. Installation Process: This one could honestly go either way.  Personally, I prefer to have a product that I can install and configure myself.  I cringe every time I hear a vendor mention to me that professional services are involved in an installation.  I get it, sometimes a tool is so highly customized to your environment that you need help, but the majority of the products I use on a daily basis aren't that way.  If installing a product requires a day of professional services time, then this should probably be your first signal to at least start looking out for the following additional signs.
  2. Initialization Script: I honestly feel a bit silly even having to mention this as I would assume this to be a standard part of any enterprise product, but it's not.  If I have to poke around in the installation directory looking for the right script to run to start or stop your product, then it's not enterprise ready.  Even worse, if it's a more complex product that requires starting multiple pieces and you don't have a single init script to handle the startup and shutdown in the proper order, then your product is not enterprise ready.  If you're trying to sell me something to make my life as a security professional easier, then I should spend my time using your tool instead of figuring out how to start and stop it.
  3. Release Notifications: If I buy a product from you and I'm paying you for support, then, I'm typically doing so with the intention that I will be able to move to the next version once it is released.  Maybe it's because there are bugs that need to be fix or because there is new functionality, but whatever the reason, I want to know when that version becomes available.  I'll talk a bit more about the upgrade process itself in the next bullet, but if the company does not have a way to notify you when a new release is available, be wary.
  4. Defined Upgrade Process: Have you ever used a tool that you thought was completely awesome until the first time that an upgrade rolled around?  They tell you copy these files over and it breaks.  Now, run this script and it fails.  You engage support and spend hours on the phone with them and then a week later they offer a webex where a support person will take care of the upgrade for you.  I had to ditch a really interesting tool a while back for this very reason and I'm currently dealing with another one where every upgrade requires a support person to come onsite.  It's a completely ineffective use of both my time and theirs.  When I designed SimpleRisk, one of the first things I considered was how to make it as simple as possible for a remote person to upgrade the tool without assistance.  I've at least got it down to copying some files and running a script which anyone can do.  Even better are the companies where it's click a button to upgrade.  Better still are the companies that just automatically do the upgrade for you.  In any case, be wary of any upgrade processes that are not well-defined.
  5. Backup Plan: This may not apply to all products or all scenarios, but it's a good idea when evaluating a product to ask yourself how you will back up the data and recover it if a disaster ever strikes.  If the answer is "We'd just wipe and reinstall", then cool, but if the answer is "F*ck, I don't know", it may be worth having that discussion with the vendor.
  6. Monitoring: Nothing bothers me more than when I'm all excited to use my shiny new toy and when I go to log in it's down.  In reality, I should know it's down when it happens because there's a high likelihood that the tool isn't doing what it's supposed to if it's not running.  Ask your vendor what you should be monitoring in order to ensure that the tool is functioning properly.  If they don't have a good answer for you, be wary.
  7. Product Roadmap: When you purchase a product, you purchase it not only for what it's capable of doing for you today, but also for the opportunities that it will provide you with tomorrow.  Ask the vendor about their product roadmap to see if it's in-line with your vision of how you intend to use the product.  Are there features that you can use down the line?  More importantly, do they have plans to continue to invest in the platform that they are selling you or is it just major bug fixes at this point while they move on to something else.  If the vendor can't give you a straight answer to this question, then you may have problems.

Don't get me wrong.  There are plenty of tools out there that fail one or more of these signs and that doesn't mean that you should completely avoid them, but you shouldn't expect to pay a premium for them either.  Hopefully the vendor is being honest with themselves and labeling it as "Beta" while they work to iron these things out.  If not, you should be honest with them about your willingness to accept a product that is not "enterprise ready".  Perhaps you're willing to accept a little bit of pain for a smaller price tag.  Maybe you want to be able to brag to your peers that you were the first to have that product hotness.  Whatever the reason, just make sure that you are aware of what you're getting into up front.


Web Application Security Roadmap – OWASP AppSec NYC 2008

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