So, in Part 1 of this series I covered a few terms and the relevant documents around CM. This time I am going to talk about models for actually doing it. I will cover a few ways that federal entities have done CM or suggest how to do it, then I will just summarize with a few take-aways you can apply to your custom CM use case.
iPost - The State Department created their own model for CM and called it iPost. iPost was mature and buzz-worthy by 2009 / 2010 and has been widely adopted since then. In addition to State, other users like NASA and the Army have adopted this model. It is based mostly on monitoring the security status of Microsoft Windows machines, using factors like vulnerability and configuration counts, patch status, and AV signature and password ages. This model was documented in iPost: Implementing Continuous Risk Monitoring at the Department of State.
The iPost model is about monitoring systems, providing numeric risk metrics on a per-host/device basis, and listing hosts by their relative risk rankings. This is all done within a dashboard that all stakeholders can see, which is important because it uses a “name and shame” scenario, ranking the best and worst and showing who they belong to. This use of pride and peer pressure drives faster improvements, but because it does an ordinal ranking of systems by highest risks, it also drives improvements to the places where they are needed first (“worst first”). iPost made State Department’s risk metrics plummet. This model had to be altered to be used by others because it was written so custom to the State Department infrastructure and policies. The more generic, more “accessible” version of iPost was rebranded as Portable Risk Score Manager (PRSM) and was made available to the public.
The best part of this model is that drives real improvements, and quickly. The worst parts of this model is that it focuses on a narrow set of risk factors, it is very Microsoft-centric, and it only accounts for a very small percentage of the controls which need to be monitored (does not address manual assessment).
CAESARS (FE) - Next, the Continuous Asset Evaluation, Situational Awareness, and Risk Scoring (CAESARS) model was developed and documented by the Department of Homeland Security, using inputs from the State Department, the IRS, and the Department of Justice. It was a more mature and extensible version of iPost, and was embraced as the basis for a set of new interagency reports (known as NISTIRs) to be written by NIST with input from NSA and DHS. I covered these in Part 1 of this series (NISTIR 7756, 7799, and 7800). .
The NIST-adapted version of CAESARS is called CAESARS Framework Extension (FE). It is designed to make the DHS CAESARS model even more extensible, scalable to the very largest organizations, and it also addressed the many non-automatable controls. CAESARS defines the components that should be present in a mature CM implementation and the roles of those components, called subsystems, which are: Presentation/Reporting, Content, Collection, Data Aggregation, Analysis/Scoring, and the Task Manager. Unlike iPost, CAESARS acknowledges that real CM “will require some human data collection effort”.
The best part of the CAESARS model are that it defines all of the possible inputs and outputs from each of the six subsystems to the other. It shows an implementer how many disparate monitoring tools can work together, maintain data integrity, and stay synchronized. It is the most technical model and is the most practical for operational considerations. The worst part of the model is the limited consideration for non-automatable controls and how to tie monitoring to compliance.
NIST SP 800-37 / 800-137 – NIST began to define a CM model with their Risk Management Framework (RMF), essentially their new way of saying Certification and Accreditation (C&A), or which some people are calling Assessment and Authorization (A&A). NIST defined how to do RMF and focuses more on integrating CM with FISMA compliance and the RMF. NIST spent less effort describing the technical details of the model and more about how it integrates with NIST RMF, FISMA compliance, and risk management overall.
SP 800-137 is NIST’s publication dedicated to CM. It describes the steps to develop a CM program and implement it. Of all CM documents, 800-137 spends the most time on the subject of manual control assessment as part of the CM scheme. It also includes a section on factors influencing the frequency of assessments which I will cover in detail in Part 3 of this series.
As you can see, each of the models has different strengths and focuses. If you want a CM capability that is no-nonsense risk reduction, and you have a Windows-heavy IT environment, iPost can help you. If you are looking for a way to tie all of your existing sensors and tools into a more robust CM model, CAESARS FE, especially NISTIR 7799 should influence your design. If you are more concerned about tying CM to FISMA compliance and/or how you will handle your manual control assessments, NIST 800-137 has the most to offer you. If you are interested in seeing a demo of how Archer’s Federal solution can accommodate all of these models, or if you have any questions/comments email me.
Come back the week of March 4th to see the third and last installment of this series, which will cover CM implementation considerations. Thanks!
Chris
