What proof do you have the incidents were managed?
What mitigation steps did you take?
What follow up steps were used?

Effective Security Information and Event Management solutions must be tightly integrated with incident management. At netForensics, we have always advocated the importance of integrating Incident Response Management with Security Information Event Management. Our nFX solutions provide a collaborative workplace for Analysts to log mitigation and eradication steps, document incident management procedures, attach additional evidence to cases, then share those procedures with other analysts.

As many Information Security organizations are required to maintain a segregated, secure environment from the IT Help Desk, investigations and breach notifications must be handled in a consistent and secure manner. nFX solutions also allow the Security Operations Center to easily communicate with the IT Operation Center on status, notification, mitigation, and eradication steps.

Security Analysts also need real-time security intelligence on complex attack vectors; from web services and hyper-visors, to database vulnerabilities and pre-zero day attacks. The nFX One Incident Response Management system enables Analysts to investigate suspicious events securely and privately. Security Operations Teams can quickly and clearly communicate with data owners, IT Management, and Operation Center personnel on the status of all critical events.

Breach notification laws concerning PII, the auditing of how the control environment was compromised, and how the Incident Management Team used evidence to mitigate the breach in the control environment - all play an important role in providing an effective Information Security Program. With the arrival of Healthcare Exchange Networks, and the importance of securing EMR records and CCHIT reviews, security event integrity and incident management are becoming critical to CMS providers and third party services/vendors that support Health Care Services.

In today's volatile security environment, internal threats are as much of an issue as external threats. netForensics integrates event correlation, vulnerability correlation and intruder security services with a complete Incident Response Management System to give Security Operations Centers real-time access to actionable security intelligence on all types of threats. Analysts have access a secure workspace that is flexible and audit-able, giving Business Operations and Management clear visibility into all threats to business processes and assets.

The Browser being built much like the Internet Operating Systems being distributed did not provide the end-user with much security protection or end-user knowledge about what all this technology meant who was managing it and what were the Risks in using it. End Users were provided these amazing services without knowing of it's fragile infrastructure. Brought to you by the same people that provided telephone and television services, end users thought that this medium would provide the same type of trusted dial-tone service they had experienced before with the telephone, television, movies theaters, public libraries, art museums, and radio.

We were all pioneers of the digital age, moving at speeds of light to connect the world to a global communications society. Today we are seeing how amazing this new technology is changing the world, as fragile as it is. Over the last few years we have also seen a new concern over this mass media speed of light world wide communications infrastructure
that is, how do we make it secure enough for the end user to trust it after so much has been published about it's security flaws?

The new language of today is Continuous Monitoring, Situational Awareness, Secure Coding, Information assurance as we try to hold on to this vast communications infrastructure of open societies. Cloud Service Providers and Software/Hardware manufactures realize to keep this technology moving forward the service needs to provide the end user that same feeling of security they feel when turning on a light in their homes.

This internet/and wireless mobile cloud services are still at the very beginning of their development as new technologies are unraveled, Service Providers are now more aware then ever that security and privacy are on the minds of all their potential customers and because if its success and impact on daily lives of it's citizens
from Banking to managing the shipment of goods, governments world wide want to make sure it's stability is not compromised by hostile forces.

On boarding trust relationships for Cloud service providers and including DNS services
will need to change. Using the Internet for Services is still a Risk Based decision.

It is always fun looking for key loggers on network shares or large multi-user storage devices using md5 checksums and other detection tools of the well known binaries you might be amazed some times when and where you find these beach heads especially on a very mobile systems that may not have strong enforcement policies or open network shares. While some corporations have very strict desktop enforcement points the majority of environments especially mobile computing environments still allow a lot flexibility to empower their employees. Key loggers can pass by some anti-virus or malware software and then their are the systems that have been infected and the desktop looks like it is running anti-virus but not.

Home users still are the target for most of these types of exploitations and beach heads for larger hanging fruit, I believe the PC manufactures should include Malware and Antivirus software that is included with the operating system that get regular updates for 4 years which is usually the life of most systems rather then the trial versions that are provisioned with most of the systems that run out and are never updated and ignored. Although China's effort to supply a national anti-virus solution was not well received by most in the security community, still it may have been a valid attempt to curb the shear mount of millions of exploited systems.

The majority of home users around the world are still open to compromise
McAfee Labs writes in their latest Blog Zeus and SpyEye old dogs repeat old tricks.
The excitement about using cloud services and Cloud Client host operating systems
may be all about usability and assurance.

If the MSPs support their clients to use managed client security services for a Cloud OS on a mobile system and support using Cloud based applications that meet the needs of the current mobile empowered user, then the need for current state of affairs of millions of infected zeus bots might change. The home user environment has always been the weakest chain, MSP services may be a way for home edition users to get the flexibility, mobility and security assurance they need to avoid exploitation but still enable application empowerment.

Dr. Kaku's discussed "augmented reality", where people can use contact lenses to get 360 degree vision by getting information from remote cameras with information being fed to us on-demand and streaming across our field of vision, and advent of real-time translation of foreign languages.

Most of these breakthroughs he explained, are already being developed and tested, including the creation of entirely new organs (livers,pancreases, and hearts) out of a mere few cells from your body or growing new ear, for example, will be commonplace.

By employing nano technology to design new versions of molecules, that when injected, will seek out cancer cells and kill them before they multiply. Diseases often take 20 years to fully develop and just imagine being able to detect them when they are only a few cancer cells in your body.

In this nano technology and quantum computing world of the future, will we reduce the threat level of technology misuse? Dr. Kaku's outlook about the future is very positive and it is interesting how he points to the role of science fiction in modern technology developments.

In Author C Clarke's 3001 the Final Odyssey, Astronaut Poole is brought back from his deep frozen space voyage. "I hope Poole told himself, that confidence is justified." Someone once said that any sufficiently advanced technology is indistinguishable from magic. Will I meet magic in this new world -- and be able to handle it?

One of the most important elements of Information Security Management is the ability for Information Security, Physical Security, and IT teams to collaborate.

A key issue any organization is effective team leadership, socialization, and collaboration. If the security team does not have the ability to collaborate or share information readily amongst themselves, there can be wasted efforts and the duplication of real-time analytics work. Information Security Management should be an enabler of team collaboration and trust.

Security Information and Event Management can provide a wealth of information but if you can not truly resolve incidents and or mitigate them, what you have is really nice log and event management with no ability to resolve them. This is why using organizations have turned to Hybrid Cloud Security Solutions for 24x7 monitoring and incident resolution.

Although this may not help in solving team collaboration issues it will be a way for your Security and IT teams to utilize expert knowledge in event identification and resolution or more importantly, the pre 0 day resolution of what is NOT currently happening, but what is about to hit... and how to mitigate that issue. If your security and IT teams have working trust relationships with their teams or other teams including Hybrid Service providers then your organization will work.

This is what NIST/MITRE SCAP is really all about; the ability for everyone to collaborate, whether it is configuration management, vulnerability assessment, situational awareness, incident response, or mitigation

• Failure to systematically respond to incidents. Systematically responding to incidents is one of the most critical factors in success incident response efforts because it involves keeping on track and following procedures based on proven methodologies. Too often, however, incident response efforts fail to develop a suitable methodology (such as the widely used PDCERF methodology that Russ Shumway and I describe in our book on incident response), or if the do, they do not sufficiently train incident response staff to follow procedures based on the methodology they use. A lack of detailed procedures that results in incident response staff having to use ad hoc judgment instead is another potential cause. A variety of undesirable consequences such as failing to perform critical steps can result.

• Neglecting to adequately test procedures. Untested procedures are a time bomb waiting to go off. Inaccuracies and omissions need to be identified and corrected well in advance of their being used when incidents occur. Additionally, testing procedures provides training for incident response team members who need to know what and how to proficiently perform each procedural step under each of many conditions and developments that occur during incidents. Without sufficient practice, team members are likely to respond to incidents more slowly and with more errors.

• Failing to work cooperatively with other groups/organizations. Incident response almost always requires cooperation among individuals, groups and organizations. Information security and HR staff need to cooperate, for example, if a data security breach involving HR servers or an insider attack has occurred. Information security and public relations staff members need to cooperate whenever an incident is so big and/or has so much impact that the press is likely to learn of it and make news releases about it. Cooperation between information security staff and law enforcement must also sometimes occur. Lack of internal and external cooperation has several negative consequences--prolonging the duration of incidents (something that escalates the financial costs of incidents), unnecessary duplication of effort, unnecessary barriers that obstruct incident response efforts, and so on.

• Communication deficiencies. Communication is one of the most essential elements in incident response, but too often communication during incidents is deficient. Procedures defining what type of information must be communicated to whom need to be written, but in many cases incident response procedures do not address critical communication requirements. One of the most important parts of the incident response communication process is escalating critical information to executive-level management. Blindsiding management often results in very negative consequences. Interfacing with human relations, legal and public relations is also too often overlooked. Communication links between an incident response team and major stakeholders is frequently not established, too. Additionally, out-of-band communication channels must be planned and tested in case primary communication channels fail.

• Lack of top-level management support. All authority in organizations ultimately traces to top-level management. Lack of support at this level often leads to failure of an incident response effort, frequently because of lack of allocation of financial and labor resources because management does not understand the importance of incident response. Lack of understanding and support can result from a lack of communication with executive-level management, failing to incorporate top-level management's intent and direction into incident response requirements, policy and procedures, and failing to educate executive-level management concerning the business need for having an efficient incident response capability.

• Lack of technical expertise within an incident response team. Many of today's incidents are extremely complex. Malicious code written by dozens of software development experts and generously funded by governments around the world is not at all uncommon any more. Handling today's incidents requires extremely high levels of technical expertise to the point that good technical expertise is insufficient. Lack of the necessary level of technical expertise results in a variety of negative outcomes, including failure to identify incidents, misdiagnosed incidents, incidents in which systems are not completely cleaned of malware, leading to unnecessary prolongation of the incidents, incidents that are handled incorrectly, causing damage and disruption to proliferate, and more.

• Lack of forensics training. Computer forensics and incident response are starting to go hand-in-hand. Every member of an incident response team needs to have at least some forensics training, and a few members need to be experts in this area. A dearth of forensics skills results in problems such as missing or mishandled evidence, incomplete or inaccurate analysis of systems and data, legal woes such as having potential evidence thrown out of court, and more.

• Failing to integrate efforts sufficiently with business continuity/disaster recovery efforts. Incident response and business continuity/disaster recovery have much in common. Lack of integration can result in incidents not being handled very well. For example, in denial of service (DoS) attacks, having business continuity staff involved brings a certain set of skills and expertise in dealing with operational disruptions that incident response team members are not likely to possess. Lack of integration between incident response and business continuity will also create barriers that are likely to result in business continuity not being involved in handling DoS attacks, or if they are involved, having them available only well after each incident has been detected. Without integration, unmitigated risk that falls between incident response and business continuity risk mitigation efforts is also likely to be present.

• Failing to determine, quantitize and communicate benefits of incident response to executive-level management. Executive-level management tends to be results-oriented. If the head of an effort such as an incident response effort does not show tangible results (particular in terms of cost savings), executive management is likely to view that effort as a failure. Developing, measuring and communicating incident response-related metrics are thus essential A few key incident response metrics include the amount of financial loss per security breach, the latency in responding to each critical security breach, the amount of business-disruptive down time per each security breach, the number of hours of labor per type of security breach (low, medium and high impact). Each of these metrics should diminish in numerical value as the proficiency of an incident response effort grows in time.

• Failure to consider legal aspects of incident handling. Many legal considerations apply to incident response efforts. Failure to conform to legal requirements can cause considerable undesirable fallout and even violation of laws leading to fines or even jail terms. For example, making a forensics backup of a hard drive of a banking transaction system and leaving it on one's desk over the lunch hour is a violation of the Gramm-Leach-Bliley Act. Additionally, inattention to legal requirements can result in inability to convict computer criminals. An example is failing to collect critical evidence needed to convict perpetrators or tainting evidence such that it is ruled invalid in a court case.

• Failure to take a proactive stance. Incident response is by definition reactive in nature, but without a strong proactive focus, incident response efforts languish. Incident response managers need to think two or three years ahead in terms of what kind of training, software, and hardware will be needed and how incident response-related policies and procedures will need to be changed. Incident response team members need to anticipate attacks and incidents that are likely to occur in the future and how to deal with them. Without a proactive focus, gaps between actual and needed incident response capabilities are likely to grow.

• Failing to use automation to facilitate the incident response process. Lack of incident response automation is, unfortunately, commonplace in organizations over the world. Today's incidents are generally too complex to handle without automation. Reverse engineering and forensics efforts now typically require at least some degree of automation. Keeping track of and archiving what often amounts to volumes of information is a voluminous task without automation. Keeping those who need to know in the loop in a timely manner is imperative; automated incident updates help considerable in this endeavor. Remembering what to do next and how to do it is also frequently a major challenge. Automation, such as the incident response facilitation that some of the best SIEM tools offer, has thus become a necessity.

In many ways, proficiently responding to incidents is the ultimate information security challenge. As mentioned previously, today's incidents have become extremely sophisticated, and attackers are more persistent in their efforts now than ever before. The number of potential serious mistakes in incident handling is enormous--only a few of the worst ones have been presented here. Fortunately, most of the mistakes discussed in this blog entry are not all that difficult to correct. For example, communications deficiencies can be fixed through changes in procedures and establishing (or improving) communications links with other groups and functions that need to be involved in the incident handling process. But above all, having a proactive focus is likely to improve an incident response effort more than anything else. In incident response, nothing is more important than planning and testing. A truly proactive incident response effort is likely to not be characterized by the types of mistakes that have been discussed here.

Incident response has become an increasingly critical function in organizations over the years for several reasons:

• Incidents have become increasingly complex and costly. Consider, for example, the Aurora attacks that started late last year. So much sensitive and valuable information was stolen (almost certainly by the Chinese) that estimating the extent of financial loss that corporations suffered became virtually impossible.
• There are three main types of controls, preventative, detective and reactive controls. Preventative controls are in theory best because they can keep incidents from occurring in the first place. But the attack surface has grown phenomenally over the last few years, and it continues to do so to the point that preventative controls are resulting in much more residual risk that ever before. Information security professionals are now realizing that a greater number of detective and reactive controls are needed if there is going to be even a chance of reducing security risk to an acceptable level. Incident response is the major type of reactive control.
• Incident response has become a critical part of organizations' due care posture. For example, ISO/IEC 27001 and 27002 list incident response as one of the critical requirements for effective information security practices.
• Legal and regulatory considerations also dictate that organizations have effective incident response capabilities. For example, incident response-related requirements can be found in both NERC/FERC and FISMA.

Unfortunately, under the "heat of battle," the probability of incident response team members making mistakes increases substantially. Mistakes during the incident response process are potentially extremely disruptive and costly, and should be avoided to the maximum extent possible. I have chosen 18 mistakes that I believe are to be avoided at all costs. They are:

• Neglecting to establish an incident response effort in the first place. This is the worst of all possible mistakes. There will be no policy or procedures to guide the incident response processes; much of what is done will be based on an ad hoc basis. Incident response will invariably be inefficient, uncoordinated, incomplete, plagued with errors, and unduly costly.

• Lack of a well-defined charter. An incident response effort needs a charter, which is in many ways a type of "license to operate." Without a charter, the responsibilities of an incident response team will not be spelled out, the scope of effort for the team will not defined, the amount and boundaries of authority that the team has will be ambiguous, and the constituency and/or stakeholders and their interests will not be delineated. Accordingly, the chances for success will be miniscule.

• Failure to set up a management infrastructure for incident response. Management is particularly critical in the incident response arena, where pandemonium usually prevails. If no management infrastructure has been established, management roles are unlikely to be sufficiently specified (if at all) and lines of authority are likely to be unclear. The position in the organization chart that incident response has will in all likelihood also be ambiguous. Who is in charge when will also be unclear. The result is likely to be a continual state of confusion during incident response operations.

• Neglecting to acquire necessary forensic and incident response hardware and software in advance. Incident response staff members need to be highly proactive in anticipating their hardware and software needs. Standard procurement procedures and obtaining forensic and incident response hardware and software quickly in emergencies do not go hand-in-hand. On-the-spot decisions concerning requirements and the products that best meet these requirements are seldom adequate.

• Failing to interface with the intrusion detection capability. Many organizations have separate intrusion detection and incident response capabilities. There may be some advantages in bifurcating these functions, but doing so is likely to produce silos that result in incident response staff not being promptly informed about incidents that occur and also not receiving sufficient information about the each incident. If intrusion detection and incident response are two separate functions, one or more response staff must continually be "in the loop" regarding intrusion detection processes. Critical tasks in these processes include documenting all relevant data and occurrences, separating real symptoms of incident from pseudosymptoms, gauging the size and impact of each incident, establishing priorities and following them, dealing with forensics considerations right from the start of each incident, and preserving the integrity and availability of systems used in intrusion detection and the data that they produce.

• Not taking advantage of Security Information and Event Management (SIEM) technology to identify incidents in real-time. For reasons I honestly do not understand, many organizations have still not implemented SIEM technology. Members of their technical staff instead tediously comb through volumes of audit log output and a plethora of alerts and warnings produced by intrusion detection and intrusion prevention systems. Consequently, organizations without SIEMs are not only wasting money (because of the amount of labor required), but more importantly are too often taking much too long to identify incidents. By the time they finally identify incidents, the incidents are likely to have escalated to the point that a myriad of systems, applications, personally identifiable pieces of data, and more has been compromised, resulting in a far higher financial cost than if the incidents had been promptly detected. The event correlation capability that certain SIEM products provide can lead to much easier and quicker detection of incidents that occur.

I'll cover the rest of the most costly mistakes in incident response in part two of this series--stayed tuned.

Procrastinators can be found everywhere, not just in university settings. In the information security arena they are professionals who delay planning and starting sorely needed initiatives and projects. They may also have an excellent security architecture, but may for various reasons have been slow in implementing critical elements within this architecture. Funny thing--so often one of the missing elements is Security Information and Event Management (SIEM) technology.

In previous blogs I have described what I believe to be the major advantages of using SIEM technology. Despite all these advantages and also considering the sorry current state of intrusion detection and intrusion prevention (with a few notable exceptions, of course), one would think that information security professionals would be lined up to purchase SIEM tools. Instead, somehow they have reasoned that SIEM technology will have to wait another year, and then when that year goes by, that it will have to wait still another year.

SIEM technology is just too critical to be pushed aside year-after-year. As I have said before, the subtle nature of so many of today's attacks has pushed event correlation technology to the forefront of detective controls. Intrusion detection and prevention tools, firewalls, personal firewalls and logging daemons may be capable of detecting pieces of attacks, but each one in and of itself is generally not capable of "seeing" a whole train of events. The result is that major attacks continue to go unnoticed for surprisingly long periods of time, with TJX's delay of 18 months in noticing the massive wave of credit card data theft that it experienced being what is probably an all-time record. (Should records of this nature also be included in the Guiness Book of Records?)

Frankly, if I had a choice between buying an intrusion detection tool and a SIEM tool, I would not have to think very hard. The same would be true if I had to decide between buying an intrusion prevention tool or a SIEM tool.

Unfortunately, not every SIEM tool is capable of performing thorough and accurate event correlation, either. Were I still a CISO, I would consider buying and using only a select few of these tools for operational purposes. A few vendors seem to have caught on to what it takes to design and implement strong event correlation capability, but, lamentably, most have not.

Procrastinators will continue to sit on the proverbial fence, but procrastinating when it comes to buying and implementing SIEM technology is just plain old every day unwise. I honestly do not understand how a CISO could possibly claim that that person's information security practice is a best practice, or even a good practice, unless SIEM technology were a big part of the security technology. It is time for us to wake up to the fact that situational awareness is now more critical to information security practices than ever before, and thus that the need for SIEM technology is today, not a sometime in the future.

This workshop being held in Denmark on Sept. 26th, 2010 on Digital Object Memories.
at the Ubiquitous Computing Conference
The integration between biological technology and nano-technology should be interesting imagine trees with the ability to store memories of it's life and times and the things around them. Sounds like science fiction doesn't it? But does the Internet of Things include biological objects? Human Memory Access probably brings up all sorts of privacy and legal issues internationally. How will all this be collected and correlated for data mining and forensics?

The primary goal of the workshop is to bring together technical experts, artists, designers, and possible end-users of Digital Object Memories in order to discuss technical, social, privacy, and legal implications of object memory systems, to establish a common view on requirements to digital memories, and to leverage cooperation in future activities. The workshop will combine traditional presentations and discussion with a practice-based experimentation.

Digital Objects Memories in the Internet of Things

Possible workshop topics include (but are not limited to):

* Architectures: General architectures and middleware approaches which allow for the realization of item memory functionality.
* Memory Content Representation and Modeling: Formats and methods for the representation and exchange of object memory content.
* Memory Creation: Technologies and concepts for the manual, semi-automatic, or automatic creation/capturing of memory content.
* Memory Mining: Algorithms to derive higher-order information like interaction patterns or state anomalies from object memories.
* Human Memory Access: Technologies, concepts, and interaction metaphors that make the content of object memories accessible to human users.
* Applications and Experiences: Application scenarios and existing implementations of digital object memory systems.
* Privacy and Legal Aspects: Discussion of topics like ownership of recorded data, access control, trustworthiness, or duration of storage.
* Social Implications: Discussion and studies related to possible implications of object memory systems on human relations to objects and other humans.

Doherty spoke today to the Information Security and Privacy Advisory Board on the risks involved with wireless network and wired network connected Embedded Medical Devices and the difficulties in mitigating those risks associated with their connectivity and vulnerabilities. There are currently 50,000 device types ranging from hand held scanners to MRI systems.

Medical Device Vendors are reluctant to patch or update devices because of the re-certification times and costs associated with getting FDA approved. Doherty mentioned that even vulnerability scans are not supported by the vendor against the devices so if there is a malfunction of the device because of a vulnerability the vendor would not support fixing the incident.

He reported that major concern recently has been the spread of malware. 50% of the malware attacks against medical devices has been conficker. This is because existing medical devices could not be patched or patched in time to avoid being infected.

Of those vendors that do allow updates, their remote access to updates for the devices are done through point 2 point vpns. There is a risk with the access to the device from the remote vendor with administrative access and the implementation of malware, although the vpns are not always online when they are, there is still a chance the download content could include malware.

The Veterans Administration does goes through very stringent C&A procedures before a new device is connected and makes sure that all of the controls in S800-53 are addressed or there are compensating controls put in place to address issues. This can often be a 6 month process before the new device is allowed online.

Doherty would like the vendors to be able to supply in-house updates via distribution centers located in-house rather then site - 2 - site vpns to the medical devices.

In my opinion, there is an equal concern not only of HIE access to Medical Records but what controls are in place that segregate access from the HIE to Medical Devices and internal IT services, VOIP, and environment equipment. I believe that there would be significant interests from attackers on the weaknesses involved in HIE access and Medical Device Systems. Medical Devices are sold all over the world, and their weaknesses would be well known -- certainly an interest to national security.

References:
http://csrc.nist.gov/groups/SMA/ispab/documents/JarenDoherty-Bio.pdf
http://csrc-nist.granicus.com/ViewPublisher.php?view_id=2

Regrettably, my faults regarding tolerance (or lack thereof) are not limited to grammar and spelling. Having once been a player in the SIEM arena for almost three and a half years, I cannot help thinking less of people who make what I think are bad decisions concerning purchasing and using SIEM products. SIEM stands for Security Information and Event Management. It consists of what used to be two fairly independent functions, Security Information Management (SIM) and Security Event Management (SEM). SIM functionality mainly includes log aggregation, log management and reporting. SEM functionality mainly includes event analysis through event correlation and possibly other methods, alerting, incident response facilitation (including trouble ticket and case creation, updating and tracking), and helping analysts in achieving situational awareness by providing network topology and other displays that pinpoint where in a network and what specific hosts and devices have been affected by incidents.

Although "we hold these truths to be self-evident, that all men are created equal" may apply to humans, it definitely does not apply to SIEM products. Many of these products, some of which sell surprisingly well, include little more than SIM capabilities. People buy these products, install and stick them in some server room while these products aggregate data that people seldom or never inspect. These people also configure reporting to obtain reports that they seldom use until they get word that auditors will be visiting them in the future, and go merrily on their way, often with the assumption that they are obtaining a very favorable total cost of ownership (TCO) because they feel they are meeting some compliance requirements by having these mostly unused and not-all-that-functional products.

Are you kidding me? What SIM products lack can sink the proverbial ship of an organization nowadays. We are getting hammered with Advanced Persistent Threats (APTs), with all kinds of attacks coming from China, Russia, Belarus, the Ukraine, Brazil, and oh by the way, also the US. The number of zero-day exploits per week has never been higher. Additionally, hundreds of new types and variants of malware are released into the wild every day. And what do SIM tools do about all this? They just sit there blissfully ignorant, unable to detect and report attacks because they have little or no event correlation functionality. Or they may have event correlation capability in name only. Frankly speaking, the proficiency of detection rules in SIEM tools designed primarily to do log aggregation, log management, and reporting is downright abysmal.

For about the same price as a SIEM tool that delivers only SIM functionality, someone can buy a SIEM product that will not only deliver log aggregation, log management, and reporting, but also all the SEM functions that are so critical, given the plethora of security threats that we currently face. How shortsighted can those who buy products with SIM but not SEM capabilities be? I don't know, but I suspect they are also the kind of people who also use "it's" in the possessive sense...

The article does point out the concerns about Cyber attacks by international criminal organizations, military initiatives of foreign nations causing massive black outs and some ways of mitigating those risks.

The article does point out another interesting point about the use of cryptography and key management. How will the keys be managed in Smart Meter technology on hundreds of millions of smart meters with pre-shared secrets or PKI infrastucture?
How will new keys be added for new energy companies? How will the keys be changed?

There is some new work being done by the Oasis Group on key management
The OASIS KMIP Key Management project may be one of the center pieces for offering interoperability across a "Trans-Smart Grid". A 2009 presentation by the University of Colorado also lists KMIP as key to interoperability. The Colorado University presentation by Dr. Edward Chow goes on to show the complexity in monitoring attacks from the trust relationships of various parts of the infrastructure including "Fake ID Hijack Station","Jamming Wormhole Attacks", "Meter Database Tampering" from Insider Attacks to External Attacks and the correlation of events moving through these trust relationships.

The Second paper from Ross Anderson and Shailendra Fuloria also referenced in the
paper Who controls the off switch is On the security economics of electricity metering .
This is an excellent paper that not only provides insight to the history of distributed power but also points out the complexities in providing modern day Smart Grid technologies not only from a technological perspective but from competitive analysis on the struggle for dominance within the distribution system both nationally and internationally and a warning on the comparisons of what happened with Enron when governance is not properly applied.