Work with federal information systems? Responsible for risk management, continuous monitoring, or FISMA compliance? Check out my book: FISMA and the Risk Management Framework.

Thursday, April 23, 2009

Balancing prevention and response

The two primary information resources with which most people are familiar for security emergency response are the Computer Emergency Response Team Coordination Center (CERT/CC) at Carnegie-Mellon University’s Software Engineering Institute and the U.S. Computer Emergency Readiness Team (US-CERT) run by the U.S. Department of Homeland Security. The CERT/CC has long been a source of valuable information for public and private sector organizations seeking information on current and former security threats and vulnerabilities. Communication with CERT is two-way, as security researchers and others send information to CERT about the latest observations from the field, and others look to CERT for up-to-date information about new threats against which protective action should be taken. US-CERT serves as the focal point of communication for U.S. federal agencies that experience security breaches or other incidents; federal guidelines mandate that such incidents (or suspected incidents) be reported to US-CERT within one hour of their discovery. Because of this reporting process, US-CERT has tended to emphasize incident response to known exploits and incidents, while directing agencies to NIST or other sources for guidance on preventive controls. The director of US-CERT announced this week that the organization would shift its focus aware from incident response towards prevention. There's no question that over-emphasizing incident response in the absence of security planning, risk assessment, and preventive controls can leads to a situation in which an organization is always one or more steps behind the attackers, always playing "catch-up" or cleaning up after an intrusion. It seems very risky however to openly de-emphasize incident response in the way that US-CERT Director Mischel Kwon does when she says "Incident response should be rare. Forensics should not be the norm." She needs to look no further than her own organization, which reports more than a three-fold increase from 2006 to 2008 in the number of security incidents reported by federal agencies, to know that incident response and forensics remain important functions in any security program intended to improve the security posture of an organization. Better and more consistently applied preventive measures, including more robust penetration testing, will hopefully help stem the exponential growth of security incidents. However, until federal (and non-federal) organizations get a better handle on how the bad guys are getting to them, effective incident response will remain a critical componet of information security programs.

Monday, April 13, 2009

Towards a more objective basis for establishing trust in information exchange

The emphasis on electronic information exchange among public sector agencies and private sector organizations has increased attention on both technical and non-technical barriers to sharing data among different organizational entities. In many ways, efforts to overcome the non-technical barriers have fallen short of their intended objectives, with the result that would-be information exchange participants who can exchange data choose not to do so because of concerns about how appropriate security and privacy requirements will be honored when the participants in the exchange are not subject to the same or comparable constraints. Some initial attempts to rationalize these differences have focused on information security controls, especially those applied at the system level. This approach cannot arrive at a mutually acceptable level of trust among diverse entities, because information system security drivers and requirements are too subjective. A more effective approach would focus on the data being exchanged, and the privacy and other content-based rules and regulations that apply to it, using these objective requirements to determine both procedural and technical safeguards needed to meet the requirements and provide the necessary basis of trust. Further development of this concept and a privacy requirement-driven framework to support it are key focus areas of our current research.