Much About Doing Nothing

One of the most important functions of a security engineer to to ensure that nothing is done.

As I write this, we seem to be in a period of historic demand for security resources; every recruiter in my region seems to be searching for candidates to fill security positions. My voice mailbox fills up once a week with messages from recruiters and hiring managers looking for referrals and my inbox contains hundreds of security job descriptions. One of the side effects of this demand zone for security engineers is an uptick in horror stories, from a wide variety of organizations, about new security people who cannot triage, or even read, security vulnerability data. Lacking the ability to thoughtfully sort the important from the trivial, some simply dump PDF or Powerpoint reports containing hundreds or thousands of vulnerability line items and demand everything be immediately fixed without regard to the importance or relevance of the issues. Others demand that any issues rated "critical" or "high" become a fire drill, requiring around the clock remediation effort and / or suspension of normal business priorities, without considering the vulns in the context of their actual risk profile and attack surface. A remotely exploitable vuln with arbitrary code execution may indeed be critical, assuming it has been confirmed a true positive, and should be patched, but if it is not exposed to unauthenticated or external users, it is probably not an emergency requiring activation of incident response plans. At the same time, the number of issues that are genuinely urgent, among those that are confirmed and serious in nature, is often smaller than those which are not urgent and may be handled by vulnerability management processes on a non-emergency basis. Vulnerabilities that are not exposed to unauthenticated users; confirmed blocked by (H|N)IDS or WAF devices; or inaccessible outside their VLAN due to layer three ACLs may not be emergencies.

This is one of the worst sorts of failure modes a security engineer can experience; a Quixotic quest to eliminate all risk creates as many direct threats to the success of the business as a security incident. Sch a quest diverts valuable engineering resources, distracts business teams, and degrades the ability of the business to execute. Additional consequences may include alienation of development and business teams, making relationship building and collaboration difficult. An efficient and accurate vulnerability management program should have at least a 3:1 ratio between asks made for doing little or nothing and asks for taking action. One of the most important functions of a security engineer is arranging for development, server, app and network teams to do nothing. This probably sounds nonsensical, but consider that security vulnerability datasets contain anything up to a 10:1 ratio between non-actionable and actionable issues. False positives abound, but so-called "nontextual" or noise line items are often more numerous. Noise issues are not false positives, strictly speaking, as the test code or criteria evaluated true and did not produce a type 1 error. Rather, they are issues that are inaccurate or irrelevant because the set of conditions the test measures does not match the set of conditions where vulnerability is present with precision. For example, some of the older vuln signatures in use may simply flag versions in service banners or port numbers. A service banner cannot measure patch levels with precision and a port number may be used by anything; when high-numbered ports are flagged on Windows servers, these are often simply the result of RPC applications allocating dynamic ports. A good security engineer would research the relevant CVE to patch mapping and identify listening services using netstat or tcpview during triage of such issues in order to eliminate them from the list of action items. In the web application space, false positives and noise abound and it can be even more important for a skilled analyst or engineer to reproduce security bug candidates..the simple presence of error messages, return codes or echoing of encoded text does not a working exploit make. In many cases, development teams are acting correctly to reject results sets from web scanners that have not been triaged or confirmed by someone who knows how to use a web proxy/debugger.

For each confirmed and important vulnerability in a data sets, there may be dozens or hundreds of such false positive and noise line items. No incremental improvement is realized by "fixing" nonexistent security vulnerabilities and tasking anyone with such issues, other than a security engineer learning to triage, is a waste of time. Whenever non-actionable issues are being reviewed, or unnecessary work is being considered, the security engineer should be fighting alongside the stakeholders for the cause of doing nothing. Given the volume of false positive and noise line items that tend to exist, a security engineer doing effective triage may spend as much or more time helping stakeholders avoid unnecessary work that asking them to do necessary work. Eliminating unnecessary work, and identifying non-urgent issues that may be deferred into routine vulnerability management or development cycles on a non-emergency basis, is one of the most important services a security engineer can provide in support of the preservation of scarce resources and the need of the business to execute.  This approach may also be successful in building effective relationships with stakeholder groups, making it easier to request action when the time actually does arrive.