Changes to FISMA

Last month the Obama administration announced new standards for agency reporting under FISMA as part of an effort to get agencies to shift from paper-based reports to real-time monitoring of systems. Vivek Kundra, the Federal Chief Information Officer, was interviewed by Federal News Radio in the post "OMB outlines shift on FISMA." Vivek expressed the vision that "What we need to do, when it comes to information security, is shift to a model across the federal government, with a focus that is much more of a real-time basis. And you'll see forthcoming, in terms of the FISMA reporting guidance, more centered on continuous performance monitoring and Cyberscope."

Ben Bain is reporting in the article, "NASA's new FISMA approach and what it means for you" that NASA’s Deputy Chief Information Officer for IT Security Jerry Davis is developing a new program for the security authorization process based on continuous monitoring, automated tools and reducing paperwork. NASA hopes to have it in place for fiscal 2011. “Security is still going to be done. Certification and accreditation will still be done, but the way we do it is going to change significantly and the frequency of it will change,” he said. “Instead of every three years, you’re really going to be doing it, in a sense, on like a weekly or monthly basis, you’re always going to be looking at those controls and adjusting them for changes."

Alan Paller, director of research at the SANS Institute is quoted on how the new approach will help to correct flaws in the original FISMA legislation, "It's a move toward being able to know the status of every machine at every minute. So that when something bad is coming at you, you know where you can target and where you can't so you can act quickly. It's a complete change from what we've had before. This started during the Clinton Administration, and it was the Senate that created it in the bill called GISRA, and then it became FISMA. It was an error made by people who didn't understand the threat, and the error was that you can manage fast-moving attacks with slow moving paper."

Joe Faraone, aka Vlad the Impaler, in his post "Machines Don’t Cause Risk, People Do!" warns that "continuous, repeatable security processes followed by knowledgeable, responsible practitioners are what government needs. But you cannot develop these processes without starting from a larger, enterprise view." Joe writes "Desiring to know everything about everything may seem to some to be a worthy goal, but may be beyond many organization’s budgets. *Everything* is a point in time snapshot, no matter how many snapshots you take or how frequently you take them. Continuous, repeatable security processes followed by knowledgeable, responsible practitioners are what government needs. But you cannot develop these processes without starting from a larger, enterprise view. Successful organizations follow this–dare I say it–axiom whether discussing security governance, or system administration."

Open Government and the Cloud

Effective security approaches being beyond many organization's budget might just be at the heart of the matter. Recall that Vivek Kundra statement that he sees two overarching trends now happening in computing:

1. The increasing use of mobile devices and the app ecosystems they support.
2. There's cloud computing, which can cut IT costs and drastically improve access to information.

With that in mind, it is not surprising that Nick Eaton reports in his post, "Obama's CIO ready to bring government tech up to speed" that the first two major tech initiative launched by the Obama administration consist of:

1. Data.gov, which is a depository for open government datasets that people can access to create applications, do scientific research and more. It launched with 47 datasets and it now includes more than 169,000. Since its launch in May 2009, New York, San Fransisco, Seattle and other local governments have launched similar services. Vivek has stated, that a big difference between public-sector and private-sector technology is that the commercial world is focused on front-end customer needs, whereas government IT is usually focused on the back end. Kundra wants to change that by creating accessible user interfaces to online government services, and as a result make "government cool again."
2. Apps.gov, which is hosted by the U.S. General Services Administration. It's a clearinghouse for hundreds of cloud-computing applications, both free and not, from mostly private vendors.

Cloud computing can be a solution that allow for continuous monitoring and a unified risk based approach across government agencies, all while reducing costs. A major stumbling block is achieving agencies compliance issues in respect to cloud vendors.

GSA Reissues RFQ

The GSA released the RFQ on its E-Buy mid-May asking for bids from IaaS providers on cloud storage services, virtual machines and cloud web hosting. Fed Cloud Blog interviewed Dave McClure, GSA’s Associate Administrator of Citizen Services and Communications, concerning the RFQ and the new contract. Dave discussed several of the differences:

We’re raising the security level to the moderate level. I think that’s where the public sector in general is headed — greater security in these cloud provisioning agreements. So, we’ve raised this up to the moderate level. I think that’s a significant improvement and difference from the prior RFQ. We also are making it much easier and clearer to map the industry offerings to the contract line items in this BPA instrument that we’re using. There was some confusion about whether specific services and prices for some of the industry offerings — how they’ve mapped to the contract line items in this BPA. We’ve gone back and actually cleaned that up and had conversations with industry on how that mapping process can work very effectively. So I think that will also create a much better instrument than what we had before. The third big difference is that things that are awarded off of this instrument will be candidates that will go into the FedRAMP centralized CNA approval process. I think that will make a difference, as well — knowing that your product or service will actually go through one CNA and then be usable across the entire government.

FedRAMP

This month FedRAMP was officially announced. Peter Mell, FedRAMP Program Manager, discusses the program in his presentation from last month. Peter explains FedRAMP is a government-wide initiative to provide joint authorizations and continuous security monitoring services. It provides a unified government-wide risk management and it will allow agencies to leverage FedRAMP authorizations (when applicable).

FedRAMP’s initial focus is on cloud computing with the program working with cloud vendors (currently Microsoft and Google are in pilot mode) to evaluate their overall security environment in relation to government security controls. The controls will be based on the new NIST security framework. There still will be some gaps between civilian, DoD and Intel agencies, so moving to cloud will still require some security work. The goal of FedRAMP is to create a unified risk management process that:

• increases security through focus assessment.
• eliminates duplication of effort and associated cost savings.
• enables rapid acquisition by leveraging pre-authorized solutions.
• provide agency vetted transparent security requirements and authorization packages.
• facilitates multi-agency use of shared systems.
• ensure integration with government-wide security efforts.

Peter states, "An advantage of this program is that [vendors] primary work with one security assessment and authorization body, or one risk management program, and they don't have to independently meet all of the security requirements of the many, many different agencies." In an interview with Eric Chabrow, Mell goes on to state, "Agencies, by leveraging FedRAMP authorization, will save a lot of money and enable rapid acquisition, but they're still in control. They get to choose whether or not they leverage it. They can choose if they want to do additional work to assure systems meet the security needs of their agency."

Mell believes the primary hurdle in securing the government adaption of cloud computing is the lack of government-wide authorization capabilities. Mell states:

Currently, with each federal agency independently doing risk management with these large outsourced systems in cloud computing you have got duplication of effort, but you have got incompatible policies being levied because the Federal Information Security Management Act is all about a framework by which agencies communicate or enforce their policies on a system. So you get 40 agencies together, enforcing their policies on a single system and the interception of those policies is likely not draftable. Likely, they will disagree on the finer points of server configuration, for example, and it just won't be possible and that is a source of great frustration for cloud vendors. It also means that acquisition is very slow, the lengthy compliance processes and then there is inconsistent application of these government-wide security programs.

To solve that, and I think this is common sense, I don't think we are doing anything unexpected or unusual here, it's certainly new, that the proposed solution is found within FedRAMP – the Federal Risk and Authorization Management Program. The idea is to create a government-wide, risk management program that has to be optionally used by the agencies. It provides joint authorization services and continuous monitoring services and again, I will stress that it is optional.

FedRAMP would perform assessment and authorization of these very large systems, these government-wide authorization then can be optionally leveraged by agencies so that they can adopt these services with a minimal of additional security effort required. FedRAMP would perform security, based on an agreed upon government-wide security baseline that agencies can leverage. That is what I mean by most of the work will be done because that baseline will have been assessed and authorized.

Agencies do have unique missions and risk tolerances and security needs, and so agencies are always welcome to do incremental additional security testing, require additional security controls to be implemented and so forth. But again, the idea is to complete the bulk of the work for the agencies; do it once and do it well and thereby reduce an enormous amount of duplication of effort and enable rapid acquisition by federal agencies, eliminate that concern of security requirements not being compatible when multiple agencies levied them on a particular resource pool cloud system. And lastly, ensure consistent application of federal government-wide security programs. The Trusted Internet Connection program or there is ITM, there is Einstein, and the list goes on

As to the question of authorization, Mell explains, "this fits perfectly within existing law, OMB policy, and even NIST security guidance. What we did do is in the new NIST risk management framework, in particular the NIST Special Publication 800-37, we added an Appendix s.6. That appendix talks about this notion of joint authorization being performed by the joint authorization board and then this concept of leveraged authorization where the agencies are leveraging the outcome of this joint authorization. We put the sort of foundational underpinnings of FedRAMP into the new NIST management framework. And by the way, FedRAMP is designed to follow that NIST risk management framework and focus a lot on that continuous monitoring aspect."

There are real issues that need to be worked out as FedRAMP develops. For example, Michael Smith in his post, “NIST Cloud Conference Recap” shares his personal experience with a certifier that said, “we don’t recognize common controls so even though you’re just a simple web application you have to justify every control even if it’s provided to you as infrastructure.” Michael goes on to list several pieces that he has not seen FedRAMP addressed yet (follow the link and read his blog). I will add two more:

1. Vendor Lock in: if a cloud provider is authorized at some point but later stops meeting the security controls causing authorization to be revoked, how do agencies switch cloud providers without cost and/or loss of service?
2. Contamination Containment: when classified material leaks into the cloud, how is that dealt with? It does happen. Current requirements are to have the drives pulled and destroyed. That is not possible under current cloud configuration where the data is spread over thousands of drives.

So, everything is not rainbows and unicorns. It never is in security. There are real challenges to be faced. It is great that a discussion is taking place and folks are working hard at addressing these issues.

Federal Cloud Adoption

This past week, a new Federal CIO Council report, "The State of Public Sector Cloud Computing" was released. The executive summary states, "As we move to the cloud, we must be vigilant in our efforts to ensure that the standards are in place for a cloud computing environment that provides for security of government information, protects the privacy of our citizens, and safeguards our national security interests. This report provides details regarding the National Institute of Standards and Technology’s efforts to facilitate and lead the development of standards for security, interoperability, and portability." Kevin Jackson in his post, "Vivek Kundra – State of Public Sector Cloud Computing" describes how the report "not only details Federal budget guidance issued to agencies to foster the adoption of cloud computing, but it also describes 30 illustrative case studies at the Federal, state and local government level."

Deniece Peterson in the post, "Security, Standards and Budget Initiatives to Spark Cloud Computing Adoption" discusses the NIST forum and workshop she attended (slides are available). Deniece describe the the morning session as including a panel of industry representatives from Intel, Microsoft, the Cloud Security Alliance, Amazon.com and the Center for Democracy and Technology. The panelists' wish list consisted of:

• Keep going with FedRAMP (security certification effort), but don't stop there.
• Develop standards in collaboration with both industry and international stakeholders
• Recognize that interoperability needs can vary case by case; no one size fits all
• Don't stifle innovation by setting standards too quickly; focus on building the framework
• ID management, access control and cryptographic key management are the main security issues surround cloud computing and can have a serious impact on scalability
• Push vendors to be more transparent about their security controls
• Traditional notions based on physical boundaries will need to change
• SLAs must include meaningful metrics for performance and security

"We want to be pragmatic, but aggressive," Kundra told the Washington crowd, noting that the government's consolidation of federal data centers and several other "game-changing approaches" will further fuel the move to the cloud. Andrew R Hickey in his article, "Federal CIO Says Cloud Standards Needed For Government Adoption" describes how NIST has also started the Standards Acceleration to Jumpstart Adoption of Cloud Computing (SAJACC) initiative that will validate and communicate interim specifications to agencies in the areas of security, interoperability and data portability. "We're not trying to write cloud computing standards, but are trying to do some testing on reasonable system interfaces or specifications of systems and make the test results available so people can see something is absolutely possible because the the test results show it," NIST senior computing scientist Lee Badger said. NIST will also launch a publicly accessible Web portal to facilitate collaborative development of standards to support cloud computing requirements, Dawn Leaf, NIST senior executive for cloud computing, told attendees. Leaf expects the portal to be available sometime before the end of 2010. Currently, business use cases are now available on the CIO Web site.

Alex Howard reports that recovery.gov would be moving to Amazon's cloud. Earl Devaney, chairman of the recovery board, stated this move represents one of the "first bricks in the foundation that we're laying" throughout the federal government, in terms of cloud computing. Vivek would direct us to "look at the Department of Interior: The CIO is considering moving 80,000 emails to the cloud. Look at the investments made at GSA or a recent RFI [Request for Information] around email. Across federal government, you're seeing a number of agencies putting in a plan." J. Nicholas Hoover reports in his article "Gov 2.0: Google Readies Government Cloud" that customers Google already has for Google Apps are the city of Los Angeles and Lawrence Berkeley National Laboratory. In the federal sector, more than 100 federal agencies are already customers of Google's other products, including Google Earth, Google Maps, and Google Enterprise Search. Google Enterprise president, Dave Girouard reports "we have a lot of state and local interest, and, increasingly, with FISMA certification arriving soon, think we have an opportunity with the federal sector." Girouard said that in addressing the federal government's unique cybersecurity demands, the majority of Google's work thus far has centered around documenting, clarifying, and explaining Google's security rather than re-inventing or changing its security posture.

Final Thoughts

Mary Engelbreit, famous children's book illustrator, once wrote "If you don't like something change it; if you can't change it, change the way you think about it." Is the government making real challenges? If so, are these the kind of changes necessary to make cloud computing a reality in federal departments?

Lori MacVittie in her post, “Can the Cloud survive regulation?” points out that “we are just beginning to see the impact of what sharing and ‘international’ really means: an increasingly complex web of requirements and regulations. That may very well make the cloud a battle-zone unsuitable for any organizational use until the conflicts between security, regulations, reliability, and privacy are addressed.” Lori also considers that we might just “see the rise of regulated clouds; clouds within clouds specifically designed to meet the demanding needs of the myriad governmental and industry-specific privacy and data protection regulations. Regulated clouds set aside – at a premium of course – for those users and organizations who require a broader set of solutions to remain compliant even in the cloud.”

In the post “Cloud: Security Doesn’t Matter (Or, In Cloud, Nobody Can Hear You Scream)” Chris Hoff offers the opinion, “the only thing that will budge the needle on this issue is how agile those who craft the regulatory guidelines are or how you can clearly demonstrate why your compensating controls mitigate the risk of the provider of service if they cannot.” Chris goes on to state, “We need the regulators and examiners to keep pace with technology — as painful as that might be in the short term — to guarantee our success in the long term.” Chris also recommends organizations “manage compliance, don’t let it manage you.” Novell has done a very funny short video based on the blog (along with other entertaining short videos you will want to check out):

I do not agree with everything that is going on in government. I believe solutions will be found through trained security professionals. Security tools can be empowering but are not the end all solution. A monkey with a computer, even if it is a high performance computer, is no William Shakespeare. Adding more monkeys will not make any difference; it just creates a zoo. I do believe in the possibilities created with change, especially when you find yourself in a place where things are not working. You build upon the knowledge of your people utilizing what does work.

What gives me greatest hope is that the federal government seems to be listening to experts like Chris, Deniece, Joe, Lori, Michael, etc. and making a solid effort to create an environment where it can foster the adoption of cloud computing. These are not just cosmetic changes focused on how we think about computing, but real changes in how we will operate. For those who like the challenges brought on by change, it is an exciting time to be in security.

Related Posts:

• OMB Says Bring on the Clouds: Frightening or Funny?
• Standardization and Interoperability in Security
• Modeling Security into the Clouds
• Recent Cloud Postings
• Provenance and Trust

ISACA does a great job of mapping COBIT to other standards. It will be interesting to see how much alignment there is between COBIT 5 and the recent work being done by the National Institute of Standards and Technology (NIST). Just last month, NIST released Special Publication 800-37 Rev. 1, “Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach.” To quote Dan Phillpott over on the Guerilla CISO site, “This document describes the central processes involved in the authorization of information systems that support the federal government. Notice I didn’t say Certification and Accreditation? That’s because C&A is deader than a sheep at a wolf convention. Want to know what replaces it?” Dan suggest picking up a copy of NIST SP 800-37 Rev 1.

Much of the recent focus on risk management is fueled by the need to deal with changing technologies. NIST SP 800-37 rev 1 is not the first NIST document concerning risk management and it certainly will not be the last. Later this year NIST will release SP 800-39 Rev. 1, “Integrated Enterprise-Wide Risk Management: Organization, Mission, and Information System View” and NIST SP 800-30 Rev. 1, “Guide for Conducting Risk Assessments.” Dr. Ron Ross presented NIST’s view of the next generation of risk management in his talk, “Next Generation Risk Management Information Security Transformation for the Federal Governmen” at the 5th Annual Security Automation Conference.

Quoting from the “Changing Technologies and the Effects on Information System Boundaries” section of NIST SP 800-37 Rev 1.:

Changes to current information technologies and computing paradigms add complications to the traditional tasks of establishing information system boundaries and protecting the missions and business processes supported by organizational information systems. In particular, net-centric architectures (e.g., service-oriented architectures [SOAs], cloud computing) introduce two important concepts: (i) dynamic subsystems; and (ii) external subsystems. While the concepts of dynamic subsystems and external subsystems (described in the following sections) are not new, the pervasiveness and frequency of their invocation in net-centric architectures can present organizations with significant new challenges.

Focusing back to COBIT 5, the planned primary improvements will consist of:

• Aligning COBIT 5 with ISACA’s TGF initiative as well as recent global governmental and market-driven enterprise and IT governance initiatives, such as sustainability and green IT.
• Consolidating COBIT 5 into a single overarching framework and knowledge base, providing one consistent and integrated source of guidance.
• COBIT 5 will be described in a high-level framework publication, providing an explanation of the objectives, scope, format and usage of COBIT 5 and enabling enterprises to strategically plan adoption of COBIT 5 and how to migrate to the new framework.
• COBIT 5 will consist of a set of publications providing:
  • The content of COBIT 5 required for enterprise implementation and assurance activities
  • Focussed guidance publications on functional, responsibility and organisational views to help
    COBIT users with a specific area of interest to better understand how COBIT can support their role.
• Clarifying the distinction between governance and management with a revised process model that distinguishes between these domains while also showing how they relate to each other, and with processes integrating both business and IT responsibilities.
• Aligning with the latest management practices as well as strengthening areas such as decision making, organisational structures, skill requirements, human factors, culture and change enablement. The new structure will be flexible, allowing future ISACA and non-ISACA standards, frameworks, regulations, etc., to be factored in.

If you want to learn more about risk management, a previous post “Risk Assessment: A Starting Point” provides a good starting point with links to some great information sources. Luke O’Connor over on Scribd, has provided some very nice graphics representation titled “How to Assess and Mitigate Risk” (a.k.a. “Six Risk Management Myths“):

ISACA is looking for feedback by the close 12 April 2010. There is also a LinkedIn Group setup by Grzegorz Albinowski where you can discuss and stay informed on COBIT 5 developments.

The Security Content Automation Protocol (SCAP) is an attempt to help defenders by providing a collection of XML schemas/standards that allow technical security information to be exchanged between tools. For example, SCAP can help organizations looking for a way to respond appropriately to new vulnerabilities and threats by helping prioritize, allowing the most significant ones to be addressed sooner. It can also benefit those looking to provide interoperability across system security tools. There is even an effort to “encouraging the use of SCAP as a de-facto standard across the ICT industry for deploying trusted cloud computing services.”

Background

To help understand what exactly SCAP is, let us turn to the U.S. National Institute of Standards and Technology (NIST) Special Publications (SP) 800-117, “DRAFT Guide to Adopting and Using the Security Content Automation Protocol (SCAP):”

SCAP comprises a suite of specifications for organizing and expressing security-related information in standardized ways, as well as related reference data, such as identifiers for software flaws and security configuration issues. SCAP can be used for maintain the security of enterprise systems, such as automatically verifying the installation of patches, checking systems security configuration settings, and examining systems for signs of compromise.

NIST this month is looking for public comments on the first public draft of SP 800-126, “The Technical Specification for the Security Content Automation Protocol (SCAP).” Back in May, NIST released the draft for SP 800-117.

SCAP components consists of:

• Common Configuration Enumeration (CCE): provide unique identifiers to system configuration issues in order to facilitate fast and accurate correlation of configuration data across multiple information sources and tools.
• Common Platform Enumeration (CPE): a structured naming scheme for information technology systems, platforms, and packages.
• Common Vulnerability Enumeration (CVE): a dictionary of publicly known information security vulnerabilities and exposures.
• Common Vulnerability Scoring System (CVSS): a vulnerability scoring system designed to provide an open and standardized method of rating IT vulnerabilities. NIST has even provided a calculator for creating CVSS vulnerability severity scores.
• eXtensible Checklist Configuration Description Format (XCCDF): a specification language for writing security checklists, benchmarks, and related kinds of documents. NIST has released the NIST Interagency Report 7275 Revision 3 “Specification for Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.4.”
• Open Vulnerability Assessment Language (OVAL): an information security community standard to promote open and publicaly available security content, and to standardize the transfer of this information across security tools and services.

The National Checklist Program (NCP), outlined in NIST SP 800-70, is the repository for SCAP-expressed checklists. The checklists provide detailed low level guidance on setting the security configuration of operating systems and applications.

In June, MITRE hosted the Security Automation Developer Days conference, which focused on the U.S. National Institute of Standards and Technology’s (NIST) Security Content Automation Protocol (SCAP). MITRE has made the minutes available, which includes discussion on NIST SP 800-126. Michael Smith has provided some great highlights from the conference in his post, “Security Automation Developers Conference Slides.” The problem with Michael is that it is difficult not to quote his whole blog, which is bad web etiquette. Please follow the link for some real insight concerning the slides. You can also view below Michael’s presentation, “Security Content Automation Protocol and Web Application Security:”

Back in September 2008, NIST sponsored the Fourth Annual Security Automation Conference. The Presentations are available. Ian Charters attended and posted his thoughts, “NIST and SCAP; Busting a cap on intruders Part 1.” The 5th Annual IT Security Automation Conference will be held October 26-30th, 2009 at the Baltimore Convention Center.

Make sure to check out below the OWASP video talk from SnowFROC 2009 by Ed Bellis (from Orbits) on vulnerability management titled “Doing more with less? Automate or die.”

Ed’s has also written an article for CSO Online, “How SCAP Brought Sanity to Vulnerability Management.”

Possible Problems

Some may argue that SCAP is overly complicated and people are better off relying solely on their vendor’s products and reports. That assumes that a single vendor product is sufficient to meet tomorrow’s security needs. Some organizations buy into the platform simplification model where basically they purchase a single vendor line of products in order to avoid interoperability problems. The problems is that one vendor frequently only does a few things well. The agility of the organization to adapt to changes in the security world becomes dependent solely on that single vendor. After investing so much into that one vendor, organizations find that they are completely locked in. Probably that is not the best position to be in when facing a very volatile IT environment.

Consider the below list where NIST outlines areas SCAP validation will cover (Source: NIST Interagency Report 7511 “Security Content Automation Protocol (SCAP) Version 1.0 Validation Program Test Requirements (DRAFT)):”

• FDCC Scanner: the capability to audit and assess a target system to determine its compliance with the FDCC requirements.
• Authenticated Configuration Scanner: the capability to audit and assess a target system to determine its compliance with a defined set of configuration requirements using target system logon privileges.
• Authenticated Vulnerability and Patch Scanner: the capability to scan a target system to locate and identify the presence of known vulnerabilities and evaluate the software patch status to determine compliance with a defined patch policy using target system logon privileges.
• Unauthenticated Vulnerability Scanner: the capability of determining the presence of known vulnerabilities by evaluating the target system over the network.
• Intrusion Detection and Prevention System (IDPS): the capability to monitor a system or network for unauthorized or malicious activities. An intrusion prevention system actively protects the target system or network against these activities.
• Vulnerability Remediation: the capability to install patches on a target system in compliance with a defined patching policy.
• Misconfiguration Remediation: the capability to alter the configuration of a target system to bring it into compliance with a defined set of configuration recommendations.
• Asset Scanner: the capability to actively discover, audit, and assess asset characteristics including: installed and licensed products; location within the world, a network or enterprise; ownership; and other related information on IT assets such as workstations, servers, and routers.
• Asset Database: the capability to store and report on asset characteristics including: installed and licensed products; location within the world, a network or enterprise; ownership; and other related information on IT assets such as workstations, servers, and routers.
• Vulnerability Database: a catalog of security-related software flaws labeled with CVEs where applicable. This data is made accessible to users through a search capability or data feed and contains descriptions of software flaws, references to additional information (e.g., links to patches or vulnerability advisories), and impact scores. The user-to-database interaction is provided independent of any scans, intrusion detection, or reporting activities. Thus, a product that only scans to find vulnerabilities and then stores the results in a database does not meet the requirements for an SCAP vulnerability database (such a product would map to a different SCAP capability). A product that presents the user general knowledge about vulnerabilities, independent of a particular environment, would meet the definition of an SCAP vulnerability database.
• Misconfiguration Database: a catalog of security-related configuration issues labeled with CCEs where applicable. This data is made accessible to users through a search capability or data feed and contains descriptions of configuration issues and references to additional information (e.g., configuration guidance, mandates, or other advisories). The user-to-database interaction is provided independent of any configuration scans or intrusion detection activities. Thus, a product that only scans to find misconfigurations and then stores the results in a database does not meet the requirements for an SCAP misconfiguration database (such a product would map to a different SCAP capability). A product that presents the user general knowledge about security-related configuration issues, independent of a particular environment, would meet the definition of an SCAP vulnerability database.
• Malware Tool: the capability to identify and report on the presence of viruses, worms, Trojan horses, spyware, or other malware on a target system.

It is difficult to imagine a single security product that is capable of doing all the above services well. There is a need to be able to share information between various systems performing these functions.

Game Changing Technology

Considering past statements by Aneesh Chopra, the first Chief Technology Officer of the United States, does not SCAP sound like an area that will be getting additional support by the U.S. government? ZDnet has posted a very interesting podcast of Chopra talking at the Computer History Museum. Chopra wrote a few months back:

If confirmed, I would emphasize a research program on “game-changing” ideas in cybersecurity, to find new ideas that might transform the nation’s information infrastructure to be more secure and simpler to understand and use. The goal is to make it “easy to do the right thing, hard to do the wrong things and easy to recover when the wrong thing happens anyway.”

Tim O’Reilly, one of the most insightful person around in respect to IT, wrote back in April “Why Aneesh Chopra is a Great Choice for Federal CTO.” Tim’s points out items that Chopra has accomplished in Virginia:

1. the first officially-approved open source textbook in the country, the Physics Flexbook;
2. integrating iTunes U with Virginia’s state education assessment framework;
3. the Learning Apps Development Challenge, a competition for the best iPhone and iPod Touch applications for middle-school math teaching;
4. a Ning-based social network to connect clinicians working in small health care offices in remote locations;
5. a state-funded “venture capital fund” to allow government agencies to try out risky but promising new approaches to delivering their services or improving their productivity;
6. a lightweight approval and testing process that allows the government to try out new technologies before making a full, expensive commitment.

Back in April 2007, Chopra was behind Virginia’s 95 agencies opening up their databases to the Google search engine, in order to make them widely accessible to the public. Chopra at that time stated the top priority of the state’s strategic plan for information technology, which was adopted last year, is increased access to government information. A great thing to do, provided security is insuring only the information you want is being accessed in the manner intended.

John Dvorak offers a different opinion of Chopra in his post “Special Report: Is US Chief Information Officer (CIO) Vivek Kundra a Phony?” Dvorak states, “It would be logical to assume that Kundra managed to get his buddy Chopra the CTO job despite the fact that Chopra’s technology background is essentially nil.” Whether O’Reilly or Dvorak is correct, Chopra needs to start reading the Guerilla CISO for great insight into security solutions. Michael outlines a plan on fixing government patch and vulnerability management through SCAP in the post, “Federated Vulnerability Management.” Here are a few of the ideas discussed in the post:

• Every IT asset reports into a patch management system of some sort. Group the assets allowing for identification of who is responsible when something has a problem.
• Do periodic network scanning.
• The orchestrator will correlate network scans with patch management status and gives a ticketing/alert/whatever where unmanaged devices are identified.
• The NVD feed is pushed down to the agencies/departments which are sent out as vulnerability alerts along with the checks to see if systems are vulnerable.
• Hardening guides are pushed from the agencies/departments in SCAP form and audit information is pulled of IT assets. Differences are automatically entered into a workflow and reporting system.

Imagine the additional possibilities when intrusion detection/prevention systems, patch remediation, asset scanner, and malware tools start sharing information.

SCAP and the Cloud

Aneesh Chopra should also read Christofer Hoff’s rational Survivability blog. In Hoff’s post, “Extending the Concept: A Security API for Cloud Stacks“, he considers building on the capabilities of SCAP to embed a “standardized and open API layer into each IaaS, PaaS and SaaS offering (see the API blocks in the diagram below) to provide not only a standardized way of scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc.” Hoff goes on to write, “Further (HT to @davidoberry who reminded me about my posts on the topic) we could use TCG IF-MAP as a comms. protocol for telemetry.”

Hoff is another person who is difficult to quote without including his complete post. He makes the point that you gain “automated audit and security management capability for the customer/consumer and a a streamlined, cost effective, and responsive way of automating the validation of said controls in relation to compliance, SLA and legal requirements for service providers.” By doing so, Hoff points out, you are “not reinventing the wheel and we have lots of technology and standardized solutions we can already use to engineer into the stack.”

Update: Hoff pointed out (see comments area) some of the excellent work done by Iron Frog (Ben) in not only his post “Some thoughts for addressing the Assurance component of A6,” but also his series of post “Can we do the Security Stack API RESTfully? (parts 1, 2, 3, 4, and 5).”

Peter Mell, who recently changed positions at NIST from the SCAP validation program manager to the leader of the agency’s Cloud computing project, will likely agree with Hoff’s points. Expect NIST efforts in the Cloud to take SCAP into consideration.

Final Thoughts

As Michael Smith points out, in the Cloud one faces the same problems as a managed service provider, mainly how to allow the auditing of systems and the underlying infrastructure. An API could allow a managed services environment making security tasks much easier to customers. To quote Michael Smith, “we have in SCAP is Common Platform Enumeration (CPE) which allows you to specify the hardware and software (ie, how the infrastructure that you don’t know about is built) and eXtensible Configuration Checklist Description (XCCDF) which specifies the audit/compliance checks. Package them together and you have a way of describing what the infrastructure looks like and the technical auditing standard to go along with it.” Sounds like some game changing ideas that could transform the nation’s information infrastructure, helping it be more secure. I hope you are listening, Aneesh Chopra.

The original slides made heavy use of the Microsoft PowerPoint animation feature. Unfortunately, SlideShare does not currently support animation. You can download the presentation and the animations will work, but I ended up modifying the slides so they are more viewable online. SlideBoom will keep the animation, but it does it by creating a video of the presentation. I decided to stick with SlideShare and spare you the resulting nine minute video. While I should add audio and make a SlideCast, this post might never be completed if I wait until I have time to create a really nice web presentation.

Merriam-Webster defines a totem as any supposed entity that watches over or assists a group of people, such as a family, clan, or tribe. In this presentation I focused on how TOTEM assists in watching over and evaluating the threat an IP represents. The idea behind TOTEM is simple: compare threat information from sources such as watchlists (DShield, Emerging Threats, SenderBase, etc.) to activities with the organization (IDS/IPS, flow logs, etc.) and other locations (SANS ISC, DOE federated model, etc.). As new threat information and activity sources are added, a better evaluation can be rendered.

The purpose of this presentation has been to share the basic ideas behind TOTEM with the hope that others may provide helpful insight. So far I have not disappointed. I wanted to thank everyone for I have received some very intriguing ideas.

What I hope people reading Cory’s post walk away with is the recognition that sects exist. We all have various fanatics at each of the organization where we work. Many are good people earnest and true in their desire to do their jobs well. Yet, they could not be more different in their solutions to the problems facing their organizations. They may fall into the high priests or heretics camps, or a dozen other camps.

Let us talk about some of the divisions within IT and security. Richard Bejtlich points out in his post, , “Steve Liesman on Inputs vs Outputs,” two camps. Richard is continuing an argument he previously made in “Controls Are Not the Solution to Our Problem.” He argues that too much time and resources are being spent on auditing controls that are far too input-centric. Instead, Richard feels controls should become more output-aware and recommends directing attention away from inputs and devoting more energy to outputs. Included are some real world examples that management could understand and relate to. Steve Liesman is quoted in relation to our current economic crisis, “It’s not what you’re doing that matters; it’s whether or not it works.” Consider the following questions. Within your security organization, who focuses on controls/inputs and who focuses on output? How much of a division exist between these groups? Where do the auditors fit in?

To point out other divisions within security, take a look at Jeremiah Grossman recent post, “Quick Wins and Web Application Security.” To quote Jeremiah paraphrasing a recent conversation with Joseph Feiman (Gartner):

During an event a panel of Gartner Analysts asked the audience what the best way is for organization to invest $1 million dollars in effort to reduce risk. The choices were Network, Host, or Application security to which the Gartner analysts made their cases for these three disciplines. The catch was the budget could not be shared between them and must be prioritized into a single initiative. The audience selected Application security. However, the Gartner CSO (who took the role of CIO in the play) overruled the audiences’ decision. They instead selected Network security, while at the same time curiously agreeing that Application security would have been the better path. His rational was that that it is easier for him to show results to his CEO if he invests in the Network.

Gary McGraw was recently interviewed by James McGovern for the SilverBullet podcast. They discuss the recent release of “Building Security In Maturity Model (BSIMM).” In the interview, Gary was asked about the leaders of the enterprises that “have a clue in making their security posture better.” While the leadership that helped develop the BSIMM had very diverse backgrounds, James asked, “It sounds like they are all from a technical background at some level. Are there IT executives out there that understand software security that are just business people?” Gary responded, “I don’t know the answer to that. I really don’t know any. I will say this about these people, they are the sort of hybrid people that can speak business and also have a very deep technical background. As you know those kind of creatures are rare on earth. Right now it appears that they might be necessary to cause software security initiatives to be a success. Hopefully, we will gain enough experience and write down enough empirical science that won’t be the case in the future.”

It is not a great surprise to learn that a major divide exists between the IT and the business camp. Recent frameworks often include governance components in an attempt to help bridge the gap between the two camps. As an example, the IT Governance Institute® (ITGI™) recently released v0.1 of risk based framework based on the principles of enterprise risk management standards/frameworks such as COSO ERM2 and AS/NZS 4360,3. The framework is called Risk IT. ITGI would argue that existing IT risk guidance documents tend to focus solely on IT security. Risk IT is meant to cover all aspects of IT risk. ITGI also develops the Control Objectives for Information and related Technology (COBIT), which is focused on “providing a comprehensive framework for the delivery of information technology-based services.” Risk IT and COBIT are meant to compliment each other. COBIT is a set of good practices which provide the means of risk management; while Risk IT is meant to set good practices for the ends by “providing a framework for enterprises to identify, govern and manage IT risk.” Recall Richard Bejtlich argument concerning the division between the controls/inputs and outputs.

All these different sects make effective security most difficult. A layered approach to security fails to work when the layers operate in isolation. Gary McGraw gets an “amen!” for describing leaders of the enterprises that understand security as a “sort of hybrid people that can speak business and also have a very deep technical background. As you know those kind of creatures are rare on earth.” On top of having an understanding that reaches into areas throughout the organization, they need to be leaders.

Rob Goffee and Gareth Jones wrote an article, “Leading Clever People.” Goffee and Jones will be publishing a book with the same title late in 2009. An audio interview is available from the London Business School. Goffee and Jones conducted over a 100 interviews with leaders at major organizations and report the relationships effective leaders have with their “clever people” can be shaped by seven shared characteristics:

1. They know their worth—and they know you have to employ them if you want their tacit skills.
2. They are organizationally savvy and will seek the company context in which their interests are most generously funded.
3. They ignore corporate hierarchy; although intellectual status is important to them, you can’t lure them with promotions.
4. They expect instant access to top management, and if they don’t get it, they may think the organization doesn’t take their work seriously.
5. They are plugged into highly developed knowledge networks, which both increases their value and makes them more of a flight risk.
6. They have a low boredom threshold, so you have to keep them challenged and committed.
7. They won’t thank you—even when you’re leading them well.

Now you may be thinking, “I am security, not the CEO of the company. I am not even their project manager. Why are you talking about leadership? What should I care about business? If users just did what I told them, life would be good.” It is important to note that a characteristic not listed above is “empathy.” Folks in your organization are not going to try and see things from security’s point of view. They want to do their job and if security appear to be a road block, they will go around. We need to avoid having each sect doing their own thing. As what occurs in many religions, an “us verses them” attitude will develop. If you want people to follow, you must first lead. To lead “clever people” you must understand those people.

James Parker, Southwest Airlines ex-CEO, offers some advice. He has written a fascinating book titled “Do the Right Thing.” One story particularly interesting concerned a manager who didn’t succeed despite being very intelligent and ambitious. “When this person finally left, I asked one of his former employees why she thought everybody disliked her former boss so much. She summed it up: ‘Because he was the kind of person who kissed up and spit down.’ ” When problems arose at American, “the primary focus of communications was blaming and avoidance of blame – in contrast, when something went wrong at Southwest, the focus of communications was problem-solving,” Parker quotes from the book, “The Southwest Airlines Way“.

James Parker and Barbara Stocking, Chief Executive of Oxfam GB, discuss below “Leadership in an Age of Uncertainty” with moderator Deborah G. Ancona. The discussion focuses on the need for distributed leadership. A key point made is that companies need “employees doing things outside the narrow scope of their job responsibilities, to contribute to the success of overall operations.” This is the cornerstone of the concept of “relational competence.”

The world continues to get more complicated. In response, more specialization occurs, which leads to less understanding of other groups. The history of religions have shown us how difficult things can get when various sects develop. In the corporate world communication breaks down, the focus on the mission is lost, and the relational competence of a company dissolves. I started this post with the statement that I come bearing no answers, only questions. While that is true, I have pointed to some very intelligent people who discuss the various sects and offer possible ways to coexist. Security professionals cannot exist in their own camp, separate from the rest of the organization, dictating how people should do their jobs. In such an environment, it will not matter if every pronouncement is the embodiment of wisdom and truth. Failure is inevitable. Abraham Lincoln offered these wise words when he addressed the Washington Temperance Society on February 22, 1842:

If you would win a man to your cause, first convince him that you are his sincere friend. Therein is a drop of honey that catches his heart, which, say what you will, is the great high-road to his reason, and which, when once gained, you will find but little trouble in convincing his judgment of the justice of your cause. If indeed that cause really be a just one.

On the contrary, assume to dictate to his judgment, or to command his action, or to mark him as one to be shunned and despised, and he will retreat within himself, close all the avenues to his head and his heart; and though your cause be naked truth itself, transformed to the heaviest lance, harder than steel, and sharper than steel can be made, and though you throw it with more than herculean force and precision, you shall be no more able to pierce him, than to penetrate the hard shell of a tortoise with a rye straw.

Amen, brother Abraham.

Basic Terminology

A good starting point in developing a risk assessment process is NIST SP 800-30, “Risk Management Guide for Information Technology Systems.” The document provides the following definition:

Risk assessment is the first process in the risk management methodology. Organizations use risk assessment to determine the extent of the potential threat and the risk associated with an IT system throughout its SDLC. The output of this process helps to identify appropriate controls for reducing or eliminating risk during the risk mitigation process.

Frequently risk will be defined as a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability. What should also be included is the resulting impact of that adverse event on the organization.

NIST SP 800-30 contains information on risk assessment and management. Recently, NIST released NIST SP 800-39, “DRAFT Managing Risk from Information Systems: An Organizational Perspective,” which contains a references to NIST SP 800-30 Revision 1, “Guide for Conducting Risk Assessments.” NIST SP 800-30 Revision 1, when it is released, will be the document for risk assessment while NIST SP 800-39 is for risk management.

Michael Smith, the Guerilla CISO, had a posting “An Open Letter to NIST About SP 800-30“. Michael writes “The best thing that you have given us is not the risk management framework, it was SP 800-30, ‘Risk Management Guide for Information Systems’. It’s small, to-the-point, and scalable from a single server to an entire IT enterprise.” I’ll leave it to the reader to view the rest of the post. The point is, NIST SP 800-30 currently is the best document to start with when talking about risk assessment.

The nine primary steps in the risk assessment methodology:

1. System Characterization
2. Threat Identification
3. Vulnerability Identification
4. Control Analysis
5. Likelihood Determination
6. Impact Analysis
7. Risk Determination
8. Control Recommendations
9. Results Documentation

Now that risk assessment is defined along with which NIST documents contains what, let us talk about risk management. Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level. The risk management process is meant to protect an organization and its ability to perform its mission. It is not just just a technical function carried out by the IT experts to protect IT assets. It is an essential management function of the organization.

Framework

Awhile back, I did a post “Intense Simplicities” which discussed the risk-based protection model verses the policy based compliance model. Several frameworks were discussed and a “Security Mappings” page was developed. Examine the frameworks discussed in the previous post and notice that basically the primary steps in risk assessment can be mapped back into the frameworks. Before developing a risk assessment methodology, consider its place in the whole risk management methodology and the framework of the organization. This allows you to utilize what has already been developed.

IT Governance Institute® (ITGI™) is also developing the IT Risk Management Framework. To quote from Urs Fischer article, “The framework aims to fill the gap between generic risk management frameworks such as the Committee of Sponsoring Organisations of the Treadway Commission (COSO)’s Enterprise Risk Management (ERM) and Australia/New Zealand AS/NZ 4360, and detailed (mostly security-related) IT risk management frameworks. Indeed, the goal of this framework is to allow organisations to understand and manage all IT-related risks (beyond security) and to address all aspects (beyond operational management of IT) when managing risk.

Information Sources

ISACA has made available a great deal of information that can be used in developing a risk assessment process. The following documents are bit older, but open to the world.

• Framing Your Choices: Weighing Three Risk Management Frameworks by Linda L. Briggs

– offers the conclusion that newer frameworks such as AS/NZS 4360 or M_o_R offer a solid route to first understanding and then controlling business risk.

• Risk Assessment Tools: A Primer – the article looks at risk assessment tools, in order to creates a framework of understanding and provides insight into the world of automated risk analysis.
• Risk Without Remorse – the article makes the argument that “by implementing COBIT risk management, the CIO should expect better portfolio management decisions and improved risk-reward communications intra- and interdepartmentwide, as well as a better ROA.”
• Risk and Control Self-Assessment (RCSA) – the article makes the argument that risk and control self-assessment (RCSA) is “a great asset in several phases of the audit process, starting with the risk assessment and development of the annual audit plan or individual audit plans of the area being reviewed.”
• IS Auditing Procedure: P1 IS Risk Assessment Measurement
• IS Auditing Guideline: G13 Use of Risk Assessment in Audit Planning
• Standard for IS Auditing: S11 Use of Risk Assessment in Audit Planing

If you become a member of ISACA, you can access more recent documents involving risk assessment and management. These include:

• A Comprehensive Method for Assessment of Operational Risk in E-banking by George Tanampasidis, CISA, PMP
• Risk Management Standards: The Bigger Picture by David Ramirez, CISA, CISM, CISSP, BS 7799 LA, MCSE, QSA
• Automating Security Policy and Procedures With Workflow: How to Improve the Effectiveness of Risk Management Solutions by Michael Godfrey
• New Framework for Enterprise Risk Management in IT by Urs Fischer, CISA, CIA, CPA Swiss

CERT just recently produced a podcast, “Security Risk Assessment Using OCTAVE® Allegro.” OCTAVE Allegro provides a streamlined assessment method that focuses on risks to information used by critical business services. The authors of the blog site, the RiskAnalys.is, are big advocates of the Factor Analysis of Information Risk (FAIR) Framework. FAIR is meant to provide a framework for understanding, analyzing, and measuring information risk.

Update:Alex Hutton provided some important clarification on FAIR. Alex points out, “FAIR is actually more concerned with the creation of accurate probabilities than how you go about _doing_ an enterprise risk assessment (because there are plenty of cookbooks for that). So FAIR isn’t actually incongruous with use in OCTAVE or 800-30 or any other assessment methodology with a ’scan/prioritize/fix/repeat/’ Deming cycle at it’s core.” Alex also provides a great pointer to the ENISA’s website which includes a comparison of the 18 different Risk Assessment Methodologies. Alex writes, “They are a little obtuse on their definitions of risk and how the 18 ass.meth.’s address their specific world view, but it is an interesting comparison document. I got a big kick out of the monster diagram that was their review decision tree.”

The ISO 27001 Security site has compiled a very nice listing with brief outlines of information security risk analysis methods, standards, and tools. IsecT Ltd., home of the NoticeBored security awareness service, voluntarily maintains the site as a “not-for-profit labour-of-love activity.” They have done a great job of keeping the site up-to-date. The site also makes available a free ISO27k toolkit. The toolkit consists of “a collection of papers contributed by members of the ISO27k Implementers’ Forum, either individually or through collaborative working groups organized on the Forum.” Three documents of particular interest are “Information security risk analysis spreadsheet,” “FMEA risk analysis spreadsheet“, and “Information security risk register.”

I tend to like information sources that are available to the public at no cost. Alex pointed out that Microsoft has put out the The Security Risk Management Guide. Microsoft describes the guide as helping explain “how to conduct each phase of a security risk management project and create an ongoing process that drives the organization towards the most useful and cost-effective controls to mitigate security risks. It incorporates real-world experiences from Microsoft IT and also includes input from Microsoft customers and partners.”

After mentioning Microsoft, I feel compelled to point out an open source project. The Security Officers Management and Analysis Project (SOMAP) is a project with the goal to “develop and maintain Open Source Information Security Risk Management tools and utilities.” SOMAP operates on the belief that “Information Security is not a competitive issue and only freely available and cooperatively developed risk management utilities and tools can potentially lead to a better security management and to further development of the whole risk management field.” They have created the “Risk Management Handbook,” “Risk Assessment Guide,” “Security Officers Best Friend (SOBF Tool),” and “Open Risk Model Repository (ORIMOR).” See their site for additional details.

Blogs

A few blog sites where information can be obtained, and questions posted, are:

• Not Bad For a Cubicle: Risk Management made interesting.
• Risktical Ramblings: Assessing, Articulating & Quantifying Information Security Risk by Chris Hayes.
• Security and Risk Management Strategies Blog: Burton Group.
• RealTime IT Compliance: This is Rebecca Herold’s site who specializes in risk assessment, gap analysis, policy content development, awareness training, strategy development and implementation. The few times I have talked with her, she has been real friendly and helpful.

Recent Blog Posts

Below are a few recent blog postings that maybe of interest. The posts were pulled from Google Reader with accompanying blurbs of text.

• Risktical Ramblings: Risk and CVSS … I would encourage anyone reading this to perform their own review of CVSS and how it can possibly augment their own risk assessments efforts. In my opinion, there are some really useful “metric vectors” that provide a simple yet powerful way to analyze a vulnerability.. …
• The Security Catalyst: Refreshing, Reloading, Refueling … My goal in writing the book was simple: present enough information to create a shift in thinking. Beyond that, a keynote, executive seminar and guided system has been developed, tested and refined to further expand on the information in the book, bring it to life and drive results. Part of our journey will be working with organizations (small and large) to implement the tenets outlined in Into the Breach to improve revenue, complete a successful risk assessment, build an awareness program that works or influence a positive change in how people, information and risk are managed …
• (ISC)2 Blog: Proving the Value of Qualitative Risk Assessments … Qualitative risk assessments are a cornerstone security management tool. This type of assessment process is characterized by estimates of asset values, threats, vulnerabilities, and costs from anticipated exposures. Risk management frameworks are a way for managers to determine where to allocate resources when risk is at an unacceptable level ….
• RiskAnalys.is: Relentless Reflection – What it Means in Risk Management … Picking up from yesterday, Today I’d like to talk about: HANSEI – WHAT IS “RELENTLESS REFLECTION?” – And why we’re talking about it in the context of Risk Analysis. Recall from yesterday’s post about how I got to thinking about the concept of Hansei-Kaizen, “relentless reflection” and “continuous improvement” and how we might apply that to risk man …
• bsi: Navigating the Security Practice Landscape … RA risk assessment (5) SA system and services acquisition (11) SC system and communications protection (23) SI system and information integrity (SI) Mappings to Other Standards Appendix G Security Control Mappings provides a detailed mapping of 800-53 controls to ISO 17799 paragraphs. Appendix H Standards and Guidance Mappings provide …
• RiskAnalys.is: UPDATES GALORE! or, THE PRONOUN “WE” MEANS YOU AND ME! …a Good Risk Assessment Methodology” – written by yours truly and Jack. It’s a very high-level document, and serves two purposes: For novices it helps parse out what is important in any undertaking to understand corporate risk (the repeated discussions on the ISO 27001 mailing list make me think it would be a place ripe for such a document). …

Build Security In (bsi) is maintained for DHS. It contains documents that are continuously being updated. The “Risk Management” area provides a framework for identifying, tracking, and managing software risks.

Only a Starting Point

Overcoming Bias, a great thought provoking blog, recently posted, “Say It Loud.” The author, Eliezer Yudkowsky, quotes Will Strunk: “If you don’t know how to pronounce a word, say it loud! If you don’t know how to pronounce a word, say it loud!” Eliezer goes on to say, “This comical piece of advice struck me as sound at the time, and I still respect it. Why compound ignorance with inaudibility? Why run and hide?” This corresponds with one of my favorite graphics created by the Creating Passionate Users blog:

Eliezer makes a very valid point. To those who “sounds clueless, but isn’t,” you need to speak up. Otherwise, you are helping the “sounds smart, but isn’t” promote their cluelessness throughout the organization.

With that in mind, let me state this loudly: the above sources will provide a very useful starting point in developing a risk assessment process. NIST SP 800-30 is the best place to start. Also check out NIST SP 800-39. The IT Governance Institute has been talking about the IT Risk Management Framework for awhile now. It should be great when it comes out, but the last I heard there was no release date set. CERT OCTAVE is freely available, so that makes it a good resource. I am less familiar with FAIR, though it looks very interesting. I tend to use COBIT when dealing with business processes as a checklist of controls to have in place. Members of ISACA should look in the journal’s archive area. The last issue was focused on risk and contained a couple of articles that would be helpful. The articles that are open to the public are somewhat dated. The blog sites will be helpful once you start narrowing in and know what you are interested in doing. In the end, this post is meant only as a starting point. It is not a complete list; not even close. While there may be a great deal more work to do, your journey has begun. Good luck.