Skip to content ↓ | Skip to navigation ↓

In the first installment of this series provided a general overview of continuous security monitoring, and the second article explained how CSM can help your organization react better to threats. The third article discussed the challenges regarding full visibility into your environment, the fourth article looked at classifying your network assets, and the fifth article in the series examined specific attack use cases.

The sixth and seventh installments looked at the Change Control Use Case the Compliance Use Case, the last installment looked at strategies for selecting a CSM platform, and this next article will examine the evolution towards CSM.

Depending on which platform you choose to build your CSM capability on, you may be simply adding capabilities to an existing in-house product, or you could be facing a rip and replace of existing technology.

In the latter case we suggest you consult the very detailed process to rip and replace your SIEM in Security Management 2.0. The technologies may vary, but the process required to move to a new platform is the same.

If you are looking at basically adding a new use case to an existing platform you can take a more streamlined approach. You still need to both plan and implement, but much less than for a platform migration.

Your plan needs to be very clear and specific about when new capabilities are added if new software or modules are required, and where any additional data will come from; then smoke-test the new functionality to ensure it doesn’t break anything and that it produces correct information; finally determine who will perform the work.


  • Identify new data sources: First you need to figure out what new data you need in your CSM platform for your new use case. For example if you are expanding from compliance to change control you will need a history of vulnerabilities, patches, and configurations so you can see the differentials. Where will you get that data? How can you automate importing the data into the system?
  • Define visualizations, alerts, and reports: Once the data is in the system, what do you do next? You need to figure out how it can help solve your problem. That means designing visualizations and/or dashboards to help make decisions. You also need to figure out which alerts and reports are relevant for your particular use case. In the planning phase you define a place to start, but that may not be where you finish. Considerable tuning will be required to make each function useful.
  • Allocate resources: Who does the work? When will they do it? How long will it take to add new capabilities? Depending on the sophistication of your use case and your internal resources, this may be a good time to engage professional services and enlist third-party assistance.
  • Define the timeline: Estimate the time it will take to roll out your new use case, including time for testing and verification. There is likely to be some ‘guesstimation’ but you just need rough numbers. Plan the project commencement date and publish to the team. Solicit feedback and adjust before commencing, because you need to share accountability with the operations team(s) to make sure everyone is invested in the project’s success.
  • Preparation: Do as much work as possible before you go into production. Depending on your platform, you may be able to set up a different instance or implementation to identify and fix issues with before they become problems in production.


  • Import new data: This varies based on the deployment model you choose (on-site or cloud), but rolling out a new use case will require you to add new data to the system. You may do a bulk import if you are pulling from an existing system such as patch or configuration management, or you might just start collecting new data as needed. This might involve installing agents on critical devices. Verify the system is collecting all the new data correctly, and that there are no issues with data accuracy or integrity. You will be making operational decisions based on this data so you need it to be accurate.
  • Install policies, dashboards, and reports: Next deploy the rules that comb through your data and fire alerts for your use case. Hopefully you created most of what you need earlier, during the planning stages. For pseudo-real-time analysis you will need to tune the rules. Each additional rule incurs a significant processing cost. It’s math — analyzing multiple data sources against many rules causes the system to do exponentially more work, impacting performance and throughput.
  • Test and verify: Are your dashboards and reports being generated properly? Are the correct alerts firing in a timely fashion? Generate copies of reports and send them to the team for review. Verify that you get what you need — now is the time to find any problems, while you can find and fix problems before they hit production.

At this point your new use case is operational and you are benefiting from continuous security monitoring. But attaining CSM is only the first part of your journey. New technology deployments and capabilities such as cloud computing, as well as emerging attacks, will require you to continuously evolve your security monitoring environment to keep pace.


Editor’s Note: This post is a series of excerpts from the Continuous Security Monitoring whitepaper developed by Mike Rothman of Securosis, and was developed independently and objectively using the Securosis Totally Transparent Research process. The entire paper is available here.


About the Author: Securosis Analyst/President Mike Rothman’s bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security — such as protecting networks and endpoints, security management, and compliance. Mike is one of the most sought-after speakers and commentators in the security business, and brings a deep background in information security. After 20 years in and around security, he’s one of the guys who “knows where the bodies are buried” in the space. Mike published The Pragmatic CSO in 2007 to introduce technically oriented security professionals to the nuances of what is required to be a senior security professional. He can be reached at mrothman (at) securosis (dot) com.


Related Articles:



picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].


Title image courtesy of ShutterStock