Lately I’ve been asking peers why they think comparably few dollars are spent addressing Web application security (by percentage to host/network), which every industry report states represents the largest information security risk. Is the reason that organizations don’t “get it”? Are available solutions ineffective? Do compliance failures need more teeth? Does the market need more time to mature? The answer is crucial, because without funds there is no way to secure the vast majority of insecure websites and we all suffer as a result. A combination of factors is probably a fair estimation, but the more I dig in the more I’m convinced something more powerful and yet mundane hides just beneath the surface. A recent conversation with Joseph Feiman (Gartner) revealed a profound insight. To paraphrase:
During an event a panel of Gartner Analysts asked the audience what the best way is for organization to invest $1 million dollars in effort to reduce risk. The choices were Network, Host, or Application security to which the Gartner analysts made their cases for these three disciplines. The catch was the budget could not be shared between them and must be prioritized into a single initiative. The audience selected Application security. However, the Gartner CSO (who took the role of CIO in the play) overruled the audiences' decision. They instead selected Network security, while at the same time curiously agreeing that Application security would have been the better path. His rational was that that it is easier for him to show results to his CEO if he invests in the Network.
Think about that!
Consider for a moment that Website Security equals Software Security, which it does plus much more. Then a maturing program will often require fundamental changes in business and code development processes. Policies need to be established, developers trained, staff hired, technology acquired, etc. An uphill battle requiring tremendous resources over the course of multiple years with scars and lessons earned along the way. As an example, the Building Security In Maturity Model (BSIMM), a real-world set of software security comparisons, observes 110 different potential activities! At the same time, measuring the value obtained from defect reduction in terms of website risk mitigation is extremely difficult. This is not to say the evolution should not begin, but it’s vital to understand the personal incentives that influence decision making.
A CIOs (and CSO) average tenure at a company is roughly 4 years, so they may view a multi-year website/software security program with immeasurable returns as a risky career move. And rightly so! If the effort takes too long and the business loses patience their credibility suffers. It is much safer to maintain the status quo spending on firewalls, A/V, network scans, and patch management where metrics are easier to quantify, report, and justify. Still, I believe CIOs want to do the right thing if enabled. So I asked my some 900+ Twitter followers (@jeremiahg) for ideas on how one might achieve “quick wins” in Web Application Security with measurable results that CIOs would appreciate. Several good ideas arose, mostly about reporting blocked attacks tied to defense measures, and interestingly not a single one mentioned the Software Development Life-cycle (SDL). I asked why, to which Chris Eng (@chriseng) of Veracode responded, “That's because SDL isn't quick.” It then becomes crystal clear why justifying a proactive budget is difficult to say the least. If we, the experts, don’t know, how can we expect CIOs to do any better?!
What happens when a website gets hacked you ask?
Simple. Risk transference and/or mitigation, but not necessarily reduction. Dollars free up shortly after an incident, but only enough to make the immediate problem go away, quickly, and usually only temporarily. Unfortunately that doesn’t necessarily translate to a lasting software security program. A CIO may first act by terminating the programmer or third-party development shop that authored the code. There is also the option of decommissioning the website entirely; replacing it with an outsourced Software-as-a-Service provider; or bring it in-house to manage internally. A Web Application Firewall could be deployed and a network scanning vendor commissioned to apply the rubber stamp assurance to show anyone asking. The point is, a CIO is compelled to demonstrate a level of success in short order and report why the same incident won’t happen again. They are caught in a position forcing them to react tactically rather than strategically.
Seriously, what other real choice does a CIO or IT Security have!? Getting hacked again and again while implementing an expensive mega software security program whose results lie years away is not particularly attractive or practical. Something needs to happen immediately. This is a big reason why accurate vulnerability assessment results piped into Web Application Firewalls (VA+WAF) has become such an attractive option. A solution capable of identifying vulnerabilities, virtually patching them, and demonstrating success to the business -- in terms of risk reduction. Quick wins are possible in a matter of days or weeks, rather than years. A similar option is desperately needed from the software development side of Web application security field. A program that produces measurable results quickly that can be built upon even after the CIO leaves. A win-win for all involved. If such a model exists, it’s not well advertised.
The only other major budgetary lever is compliance where justification occurs without consideration of or a requirement for risk reduction, “We need money to do X because the standard says so.” For myself, and I think many others too, that is just not good enough. Lest we forget, compliance != security. So I’m asking again...How do you achieve quick wins in Web Application Security, rooted in software, with measurable results that CIOs would appreciate?
The answer for this kind of questions presented differently by each company. Too many angels.
I'm still looking for a good comparison list of different WAF's solution.
@Karen, you are exactly right. Recommended paths towards website security are going to "depend" on each organization. There in lies the problem, but I think we can all do better.
I've not personally seen any decent head to head WAF reviews lately. Essentially few are in business to actually do them anymore. Best we can expect is experiences shared by those who've tried them. If you are looking at a particular product, I can probably put you in touch with someone who has implemented such a device.
... but SDLC is the right approach though. CIOs may not be able to launch company-wide SDLC program in short time frame, but they can start with pilots and proof of concepts on a chosen app. Done right the method will replicate "the right way" to the rest of the apps. Implementing WAFs we choose to abstract from the code even further. WAFs do not solve business rule violations leading to funds transfer, for example. On the other hand, let's look back at a QA/Dev guy who is more than capable of instrumenting the code with security point probes on which the organization can report. For example, the function checking for validity may count the number of times "really bad" input was submitted and provide such statistics for ROI calculation. QA knows a lot more about code coverage and test harnesses than is being utilized by organization.
I think that if time was spent in creating an effective risk determination methodology that is repeatable, it should give management enough of a mechanism to report progress. I can understand that CIO's need to justify their security initiatives, and they should to ensure that the best thing is being done for the organization, but using risk as the ammunition for this justification should allow for ALL initiatives to be be justified and to ensure a proper return.
"A similar option is desperately needed from the software development side of Web application security field."
While a solution for code reviews that offers effective (not automated code scanners), yet efficient (not manual reviews) would be wonderful, and might be just the ticket to offer quick and measurable results - much like Sentinel on the PT side, or VA+WAF - this has not been possible...
Until very recently. I recently launched our CODEFEND service, offering just that. We can quickly get in deep in the code, and offer fast responses, down to "fix this line and change to that". And as soon as this is implemented by the programmer, we can verify the fix and show some hard numbers on the code's security.
And yes, it is scalable. :-)
(forgive the semi-marketing-speak, but I believe its in all our interest)
Post a Comment