Lots of recommendations for new cyber-security czar

Ever since President Obama announced his intention to appoint a federal cyber-security “czar” in the Executive Office of the President, there have been a steady stream of open letters and articles making recommendations for the as-yet-unfilled position, as well as expressing concerns about the obstacles such an individual will face in being effective in the role. Adding to the unsolicited opinions this week is a succinct and thoughtful piece in Federal Computer Week by SANS research director Alan Paller, “The limits of a cyber-czar.” Paller highlights three of the many issues with the current state of information security in the federal government: too many integrators and vendors delivering systems that include security flaws or vulnerabilities; a lack of technically qualified security personnel; and a general failure on the part of government auditors (and agencies themselves) to assess the effectiveness (rather than just the implementation) of existing security controls.

Paller’s point (and mine in highlighting his article) is not just that these three issues represent big security challenges for the government, but also that they are issues that the new cyber-security czar may be able to take on an influence. Of course, not all aspects of federal information assurance are well-suited to top-down management or to common solutions, but with the emphasis to date placed on the role of the cyber-security czar in formulating and implementing policy for the federal government, these do seem like fruitful areas for exerting some executive branch influence. For the software security and general quality issue, the czar need look no further than the Department of Defense for standards, contract language, and requirements that demand vendors and integrators demonstrate that their products and developed systems meet specific security configuration criteria, such as those contained in the DISA Security Technical Implementation Guides (STIGs). Paller points to sparse implementation and enforcement of the Federal Desktop Core Configuration (FDCC) requirements that officially went into effect in February 2008, and lays the blame at the feet of the agencies who appear unwilling or uninteresting in explicitly requiring (and holding to account) their contractors to comply with the existing standards and rules. The scope of the FDCC is much narrower than that covered by the STIGs, so any federal-level policy about security standards should look beyond merely requiring FDCC compliance.

On certifying security workers, Paller calls out the DOD for having the right intentions (to require personnel with security responsibilities to be certified) but in short-sightedly lowering its technical certification standards. It’s a bit of a funny argument coming from Paller, given that the SANS GIAC cert is among those (along with the CISSP from (ISC)² and CISA and CISM from ISACA) fulfilling the DOD certification requirement. It is true that in rolling out the DOD 8570 certification rules, DOD has included several certifications traditionally aimed at infosec managers (rather than hands-on practitioners), and that many of these are broad-based in nature rather than deeply technical. It is also true that the SANS set of certifications underlying the GIAC do tend to require much deeper mastery and demonstration of technical skills than DOD-approved certs from other organizations. Again using DOD as a model (even if its experience hasn’t been perfect) for how minimum security qualifications might be both required and demonstrated for federal infosec workers, the cyber-security czar could put in place personnel policies that would (over time) raise the level of competency in the federal security workforce.

The toughest nut to crack for federal agencies may be first assessing and then improving on the effectiveness of security controls implemented within the government. Even with the very positive development seen with the third revision of NIST Special Publication 800-53 that will standardize the set of controls for all government agency systems (Defense and Intel included), 800-53 is still used primarily as a planning or implementation checklist, and not as a basis for evaluating security controls put into production. It remains to be seen whether the cyber-security czar, perhaps under whatever framework emerges for the revised national cybersecurity initiative, can craft a policy to require penetration testing and specific audit procedures that go beyond the documentation-validation exercises so prevalent today, and work with agency CISOs to see it implemented.