While I recognize no software is 100 percent bug free and that the world of threats is ever dynamic, customers, consumers and enterprises need their vendors to take the entire life cycle of security management far more seriously than is evident from their behavior today.
Vendors must focus on dramatically reducing events that bring about zero-day exploits that leave security professionals holding the bag and praying nobody opens an attachment.
Vendors that talk about security must deliver evidence that matters. In the big picture, it's clear that features and functionality that drive some level of economic gain are often prioritized over security. This leads to situations in which the buyer is left struggling with unnecessary risk on their own. This situation is ultimately untenable for both producer and consumer.
Budgets are always undersized for cost centers like IT where effective resource planning can determine success or failure of many projects. With the current economic situation, IT belts are getting even tighter. Resource-constrained IT teams cannot afford to be derailed by vendors that haphazardly release security patches and offer little or no mitigation information.
Security should be part of every organization's DNA. We as consumers, enterprises and partners shouldn't have to ask the vendor to take their role more seriously.
Vendors must aggressively demonstrate their commitment to our security by putting their resources where it matters, including:
Common metrics. How does a Microsoft “critical” security bulletin compare to a CVSS score or with Adobe's definition of “important”? Customers require a common way to derive global risk in order to methodically protect their own network in a reproducible manner. CVSS may not be a perfect scoring system, but it is open, multifactor and adaptable. From now on, I implore all vendors to adopt a common risk classification system by including a CVSS score with each and every CVE patched.
Since all vendors should be publishing information that contains the common element of CVSS, vendors should also release statistics on their own bugs on a quarterly basis. Obviously, vendors with better statistics will be viewed as more mature, and this in turn will drive new marketplace dynamics where vendors compete to be the ones delivering the most secure applications and buyers are willing to pay a premium for that security.
Communication and coordination. Communication is a highly valued skill for every employee, and effective communication within an organization can make or break company success. Why was the Dan Kaminsky DNS patch in 2008 of such interest to non-techies? The reason was communication and the leadership role he took on to coordinate a fix among dozens of vendors. Dan's behavior was a ray of light in an otherwise clouded and messy industry.
All vendors should take security communication seriously and begin speaking with each other. There is no reason for Oracle and Microsoft to be releasing patches on the same day (as they did in April this year), or as Apple, Adobe and Microsoft did in May. The corollary to this rule is that a bug spanning multiple vendors and products should be released at the same time to enable customers the maximum remediation window and minimize their efforts to reduce risk.
In addition to communicating with each other, vendors must do better at communicating with their customers. IT security teams ask that vendors provide a minimum of 24 hours notice for impending bug fixes to allow for resource planning. The days of unexpected patch releases that make it impossible for IT teams to attend their kids' baseball games or finish their existing projects before a Friday deadline should be over and gone forever. Vendors absolutely know when they are going to release a bug fix. It's not too much to ask them to share that knowledge with their customers.
While vendors are reworking their communication skills, they should also publish consistent and complete bulletin data with every patch release. The bulletin must include at a minimum: A summary, severity rating including CVSS score, affected software versions, mitigation factors and acknowledgements to the reporter. No published data should ever be deleted. The value of transparency to all customers is far greater than trying to “spin” an event after the fact.
And while we are at it, why stop there? Vendors should also stay in regular contact with each other for the purposes of understanding current risk trends. For example, why don't anti-malware vendors report to the software development community if they find active exploits? It only stands to reason that software flaws should be communicated among the industry partners, including IPS and AV vendors, so that they can more quickly implement some level of protection while patches are being developed.
Mean time to repair. Though nobody expects all products to be completely error free, we do expect the vendor to take all security issues seriously. Vendors should commit to confirming any reported bug with the reporter within five business days. Further, the vendor must commit to releasing a fix within 90 days and to maintaining contact with the bug reporter during this time.
What else can vendors do during those 90 days when security teams are sitting white knuckled in their cube chairs? They can use the mitigation information, complete and well documented, to help reduce the risk. Vendors should release tools and methods to centrally deploy mitigation factors. And, if during those 90 days the vendor learns by communicating with other companies that risk is heightened, then the bug fix should automatically get fast tracked.
Leadership. Vendors must appoint an employee who is both accountable for product security and effective at producing change within their own organization, and hopefully, within their industry.
In the 1990s, Microsoft's product security issues were a liability for consumers and for Microsoft. The enterprise couldn't live without Microsoft Word, but also was hesitant to invest in more Microsoft products because they increased enterprise security risk. Microsoft security is quite different today. While bugs are still found in Microsoft products, the company has become a proactive leader in understanding and improving the lifecycle of product security during the last five years.
The bottom line
The bottom line is that enterprise security teams are exhausted from running for their lives on the hamster wheel of never-ending patches. Running for our lives to reduce risk is by no means what we are employed to do.
IT is supposed to be a catalyst for enablement and empowerment. We want to give new and better tools to our internal customers, not ask them install patches and reboot every day. Time lost and money spent on tracking vendor security issues drives down our own efficiencies, and this in turn drives down the overall effectiveness of every organization. Vendors, I implore you to make security a strategic priority for the betterment of us all.
