benveniste

A lot of people are slamming Equifax for not patching their system once the vulnerability became public. But so-called "best practices" for Patch Management strongly suggest a delay before deployment, just in case the cure is worse than the disease. You can find the NIST document on the subject here.

That document is little changed from its 2005 predecessor, while the nature and severity of threats has changed immensely. As a result, corporate security groups have grown both in size and visibility. Inevitably with such growth, process replaces common sense in decision making. So while the NIST document does state, "in some operational environments, such as virtual hosts with snapshot capabilities enabled, it may be preferable to patch without testing as long as the organization is fully prepared to roll back the patches if they cause usability or functionality problems," suggesting such action becomes a career-limiting move.

I'm willing to bet that the patch for this particular vulnerability was "in the pipeline" at Equifax. Nor, from my experience, is a two month delay anything unusual in a large company. All that process, meetings, and documentation take time, after all, and any patches outside of a scheduled deployment "window" requires even more approvals.

While it's easy to say that this mindset should change, history shows us that it's nearly impossible. Large organizations are never going to be as nimble as a start-up, let alone as nimble as a small group of "bad guys." So while Equifax should have been able to reduce the window of vulnerability to, say, 2 weeks instead of 2 months, I fear that window will always exist.

The software bug which gave the "bad guys" access to Equifax was in an open source project called Apache Struts. It was one of two critical software bugs found in that project so far this year. The source code for Struts is available online, for free, for anyone who cares enough to look at it. The bad news is that there is no way to hide weaknesses from "bad guys" with the skill to find them. But that also means there is no way to sweep weaknesses "under the rug," and no incentive for a developer to hide them. It is one of the axioms of open-source software that this benefit outweighs the risk, since bugs get detected and fixed sooner.

Whether open-source software in general is more or less secure than proprietary software is a continuing debate. But I think these Struts exploits show a weakness in the open-source assumptions. Struts is, shall we say, a "mature" offering. It's widely used, but there's no real excitement or positive "buzz" about it in technological circles. There's not a lot of "egoboo" or career advantage in contributing to the Struts project anymore. The combination of widespread adoption, source code access and developer ennui makes it an ideal target for hackers.

Speaking in generalities, software developers seek out the "latest and greatest" technology, while management types will often preferred "tried and true" solutions to reduce risk. Both viewpoints are valid, but like every product, software has a shelf life. With commercial software, the need to move off of stale software can be enforced by the vendor discontinuing support or simply going out of business. But I think the industry has to pay more attention to these "stale" open source efforts as well.

Through the CVE-2017-5638 exploit, the "bad guys" obtained the ability to execute arbitrary commands on Equifax's public facing servers. This is never good, but everyone knows it can happen. Once again, there are a series of "best practices" for such systems, and I have little doubt that Equifax's CIO thought they were using them. And indeed, the "best practices" do guard against a variety of once-common threats.

But here's the thing. The exploit could only give unlimited access to the attacker if it was running with administrative, or "root" privileges. Those "best practices" state that server-side software should run under an account with as few permissions as possible. Nor should any of those commands allowed access to other systems except through a controlled number of paths, and none of those paths should have allowed access to large quantities of data at a time.

Equifax is doomed to become a case study of "insecurity by design." Border security alone is never sufficient; for a high-profile target like a credit reporting agency, it has to be though of at every step of the process. For example, putting a database "behind the inner firewall" is useless if the DMZ machines can make arbitrary queries. Sanitizing inputs to prevent "little Bobby Tables" attacks is well and good, but once you reach a certain risk level, further measures are needed.

I guess it's that time again.  Everyone seems to be asking, "Why can't we build a high speed rail network?"  In at least three different venues, I've seen people either asking that question or linking to articles such as the one from Brookings claiming it's due to a lack of political will.

• 70% of the regularly scheduled trips on the commuter Rail


• Fewer cars and less frequent service on the Blue and Green lines


• "Limited" Service on the Red and Orange lines

• Ridership as measured by unlinked trips is up 5%


• Total Operating Costs are up 46%


• Wages are up 27%


• Fringe Benefits are up 26%


• Outsourced Expenses are up 78%


• Percentage Revenue from fares has dropped from 35% to 33%


• Unless it's hidden in the "Materials, Supplies, and Services" catch-all, depreciation is not included in determining deficits or surpluses.