Perimeter
5/10/2011
11:44 AM
Commentary
Commentary
Commentary
Connect Directly
RSS
E-Mail
50%
50%

A National Monitoring Infrastructure

It's theoretically possible, but who could orchestrate such a huge collaborative endeavor, and would it be possible to bring both private and public data under government oversight?

I recently had the opportunity to read Edward G. Amoroso’s book, entitled ""Cyber Attacks: Protecting National Infrastructure"," about the concept of a national-level infrastructure for the collection, correlation, monitoring (which he calls awareness) of, and response to cybersecurity incidents. As I read the four chapters, I found myself doing a little correlation of my own and drew several parallels to the Enterprise Security Information Management (ESIM) sector.

What Amoroso is describing is essentially a "master ESIM infrastructure" -- taking feeds from both public- and private-sector entities with the goal of centralizing data from the citizenry, business community, and government for the purpose of large-scale trending and worm detection. The idea sounds like a good one, but I have serious doubts about the ability to manage an infrastructure of such monstrous scale.

Although an effort of this design would be useful, it is very unlikely that a nation’s citizenry would trust the government enough to allow for the collection of data from its personally owned technology products. Enterprise customers have their own problems to worry about at a macro level without even considering participating at a super-macro-level for a national monitoring infrastructure. Compliance mandates, impending audits, and organizational security concerns will almost certainly trump national defense -- especially since many organizations consider the defense of the nation to be the problem of the elected government.

If the national-level collection infrastructure were limited to a cybersecurity mandate, however, military branches, in addition to government and intelligence agencies, could wield a national ESIM to better defend their interests. Once implemented, this national ESIM could expand to encompass public utilities and the military industrial base of defense contractors and SIs with which it partners to further national interest. Really, any organization or vendor with ties to government’s defense could be directed to submit to a national ESIM mandate in the best interest of the country’s defense. A major obstacle to hurdle is that many departments, divisions, and federal entities rely on their own ESIM deployments to manage the cybersecurity concerns within their own small spheres of control.

Unfortunately, not all of these deployed products are capable of promiscuously interoperating with one another -- many contain proprietary data stores and formats with no common interface for data sharing. Technical issues aside, the political power plays around information sharing among government entities has never been an easy bridge to cross. Each organization really cares only for its own sphere of control, and sees the request for information from external agencies as an invasion of their sovereign fiefdom.

Perhaps the only way that a national ESIM infrastructure could work is if such an endeavor were mandated by the government and its purview assigned to a coordinating body, such as the Department of Homeland Security (DHS) -- a thought that would make those already concerned with the power wielded by the agency exponentially more nervous. Unfortunately, one organization would need to coordinate everything, and DHS might be the only agency that could wrangle the disparate pieces of government into submitting to such a plan. Even with DHS in charge, I wouldn’t anticipate a massive rip-and-replace of existing ESIM products, but the agency could dictate that vendors share information between one another or risk being replaced.

Andrew Hay is senior analyst with The 451 Group's Enterprise Security Practice and the author of three network security books. Follow him on Twitter: http://twitter.com/andrewsmhay.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3090
Published: 2014-09-23
IBM Rational ClearCase 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 allows remote attackers to cause a denial of service (memory consumption) via a crafted XML document containing a large number of nested entity references, a similar issue to CVE-2003-1564.

CVE-2014-3101
Published: 2014-09-23
The login form in the Web component in IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 does not insert a delay after a failed authentication attempt, which makes it easier for remote attackers to obtain access via a brute-force attack.

CVE-2014-3103
Published: 2014-09-23
The Web component in IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 does not set the secure flag for the session cookie in an https session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an http...

CVE-2014-3104
Published: 2014-09-23
IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 allows remote attackers to cause a denial of service (memory consumption) via a crafted XML document containing a large number of nested entity references, a similar issue to CVE-2003-1564.

CVE-2014-3105
Published: 2014-09-23
The OSLC integration feature in the Web component in IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 provides different error messages for failed login attempts depending on whether the username exists, which allows remote attackers to enumerate account n...

Best of the Web
Dark Reading Radio