Continuous security monitoring: What enterprises can learn from CDM

Uncover key continuous security monitoring tips enterprises can take away from the federal government's Continuous Diagnostics and Mitigation program.

Lost among the fiery rhetoric of the 2013 government shutdown, the debt ceiling, budget negotiations and the ongoing political posturing, a large and expensive government program has steadily advanced toward implementation in recent weeks.

Unaffected by current events -- and in receipt of an initial allocation of $150 million -- the General Services Administration in conjunction with the U.S. Department of Homeland Security (DHS) has begun working on what the federal government termed Continuous Diagnostics and Mitigation (CDM). Known by many entities not affiliated with the government by its more common name, continuous security monitoring, the rather lofty goal of this project is to implement continuous monitoring of the federal government's most critical network resources using the latest technologies and standardized policies.

Enterprises can learn a lot from the government's endeavor. Using this effort to set the table, let's delve further into the concept known as continuous security monitoring and explore how your organization can benefit from its implementation.

Defining CDM and CSM

The CDM program is a blanket purchase agreement that helps nearly two dozen civilian-managed federal government agencies purchase products for continuous security monitoring (CSM) that fit into the approved architecture designed by DHS. While the agreement has a $6 billion ceiling, individual agencies remain responsible for funding their own purchases under the agreement.

Simply put, CSM is the constant checking of the most critical network resources in the enterprise. By using the term continuous, the implication is that certain assets will be monitored 24/7/365 and, should any anomalies occur, some sort of alerting mechanism will notify system administrators accordingly. Though CSM has, in fact, been around for quite some time now, a specific term was not coined until recently.

For several years, the de facto enterprise network security strategy was to monitor and protect the network by implementing various intrusion prevention/detection systems (IDS/IPS) in conjunction with some sort of logging mechanism. However, as both security professionals and enterprise networks grew more sophisticated, more all-encompassing solutions were created and adopted. Fast forward to today and a full-blown CSM solution is being advocated and supported by no less than the federal government itself.

With the CDM program, DHS is focusing on getting agencies to implement a six-step CSM process: installing and updating network scanning sensors, automating the search for known system flaws, collecting the scanning results, triaging and analyzing the results, initiating mitigation of the biggest or worst flaws, and reporting progress. The objective is to enable civilian agencies to fully diagnose their networks within 72 hours of sensor deployment.

While it remains to be seen how successful this program will be, it's clearly an ambitious effort backed by a major purchase agreement. If successful, there's no doubt it will go a long way toward improving information security within federal agencies. In describing the potential of the program, the SANS Institute's Alan Paller said CDM "will transform the landscape in cybersecurity tools -- as critical infrastructure and other corporations take advantage of the lessons learned on how to prioritize cybersecurity expenditures and how to stop wasting so much money on high-priced, low-impact tools."

Enterprise CSM: Getting started

So how do private enterprises follow the government's lead to implement this sort of continuous security monitoring? While decision makers could opt to purchase any number of commercial monitoring products from vendors like Symantec Corp., Tenable, TripWire Inc., FireMon Inc. among many others, chances are most enterprise networks have some version of the necessary tools in place to get started. However, before tools are discussed, let's take a look at an important piece of the CSM planning process: device classification.

Prior to implementing a continuous monitoring system, a decision must be made with regard to which network components and segments should be prioritized for continuous monitoring. Resources to deploy sensors and interpret the results are limited, so enterprises should adopt a risk-based approach to deploying CSM. Begin with your most critical assets rated by data sensitivity and/or mission criticality. The networks containing the largest numbers of these systems are the prime targets for initial CSM deployments. From there, you can continue to expand your efforts to other network segments using a risk-prioritized approach as resources permit.

Enterprise CSM tools: Using what you already have

With regard to which in-place tools can be used for continuous security monitoring, note that the following is not considered a long-term substitute for a dedicated CSM system, but more of a stop-gap. If an organization currently maintains an IDS/IPS, a vulnerability management product, a network enumeration solution and some type of network logging mechanism, it is well on its way to implementing a "poor man's" CSM system.  

When it comes to IDS, a popular open source product is Snort by Sourcefire (now owned by Cisco Systems Inc.). This popular product provides a very flexible rule management system that allows you to accept updates from the community and supplement those rules with your own custom scripted rules that monitor conditions on your network.

Network enumeration

One often overlooked part of CSM is the concept of network enumeration. This has become especially important with the growing popularity of bring-your-own-device policies in today's enterprise networks. Simply put, it's tough to continuously monitor something that you don't know is there. While network enumeration tools are many and varied, one that is extremely popular, easy to use, time-tested and open source is called Nmap. While different graphical user interfaces exist for it, Nmap at its core is a command-line tool that, much like Snort, is highly scriptable. For example, if system administrators know that their internal network IP scheme is 10.0.0.0/16, then in order to locate every device within that network range, they should type the following command:

nmap 10.0.0.0/16 >> mytextfile.txt

This command tells the Nmap tool to locate every device on the network within the given subnet and output the node information to the text file. This will help system administrators better identify all networked devices.

Logging: CSM won't be successful without it

The last and perhaps most important aspect of continuous security monitoring is logging. Logs provide a critical audit trail of activity on systems and networks, allowing security professionals to reconstruct the events leading up to a security incident. Log analysis tools detect problems and identify security issues that might otherwise go undetected. For example, log analysis might be the only source of security information on an insider attack that takes place via direct login to a sensitive machine and does not generate network traffic.   

Much like network enumeration tools, logging tools are many and varied, but it's safe to say that a very popular (if not the most popular) logging mechanism in the enterprise today is the Linux service known as syslog. Because syslog is so highly scriptable and extremely granular in its level of data collection, many enterprises find that they can easily tailor their logging functionality to their specific organizational needs. For example, if system administrators would like to send all of their Snort alerts to their syslog server, they would navigate to etc/snort/snort.conf and add the following to the end of the configuration file:

output alert_syslog:host=10.0.0.1:514, LOG_AUTH LOG_ALERT

The above command presupposes that the syslog server has an IP address of 10.0.0.1 and that it is listening on UDP port 514. This command is especially useful and highly scalable in the event that system administrators configure alerts to record anomalous inbound and/or outbound connections, the insertion of new devices within the local area network or any other network event that administrators deem alert worthy.

Conclusion

Continuous security monitoring is gaining traction within both the federal government and the private sector. Homeland Security's CDM initiative provides a common framework for federal government users and also outlines a deployment approach appropriate for enterprises of all stripes. The availability of this framework, along with the blanket CDM purchase agreement for a variety of security monitoring tools, should drive adoption within the federal government. This drive from the federal government will likely spill over into the private sector, creating a new sense of urgency around the deployment of security infrastructure throughout public and private networks alike.

About the author:
Brad Casey holds a Master of Science degree in information assurance from the University of Texas at San Antonio and has extensive experience in the areas of penetration testing, public key infrastructure, VoIP and network packet analysis. He is also knowledgeable in the areas of system administration, Active Directory and Windows Server 2008. He spent five years doing security assessment testing in the U.S. Air Force, and in his spare time, you can find him looking at Wireshark captures and playing with various Linux distributions in virtual machines.

This was first published in January 2014
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close