Today's privacy laws, breach notifications, and other compliance requirements have further escalated the role of incident management in an effective security strategy. It is no longer enough to just log security events for the auditors, but organizations must also carefully review how incidents are managed and mitigated, correlating event tracking with how the incidents were managed.

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 adoption of virtual firewalls and IDSs has begun to rapidly accelerate among Managed Security Service Providers. Virtual devices, including Juniper Vsys, Cisco ASA Virtual Context Features, Checkpoint VSX, Fortinet VDOM, Cisco VSG, and Vmware Vshield, work similarly to their physical counterparts and use industry standard VLAN technology. Virtual firewalls are particularly advantageous for service providers as they can manage hundreds of domains utilizing only one or two physical devices. Therefore, costs and complexity are reduced while consistent service levels become easier to maintain. nFX One solutions enable MSSPs to cost-effectively integrate, monitor and correlate data from these virtual environments. Utilizing nFX rules based event routing, service providers can map virtual firewalls to specific MSSP customers and easily manage and route events. - Bill Leroy

In the recent Article published by CRN
Comodo Attack Sparks SSL Certificate Security Discussions.
Brian Price writes about the Security and Trust of Internet Certificate Authorities
"A spotlight on one of the basic issues of the Internet -- proper authentication". Certificate Authorities have been one of the largest Cloud Security Services that implied a certain amount of trust for the site was established the content holder was verified by Dunn and Bradstreet the person requesting the certificate holder needed to have a Corporate Officer verify the request of the Certificate was authorized etc... The CA Authority was thought to be under the tightest security requirements to protect top level Trusted Servers. As time passed on more and more Certificate authorities came on line with competitive pricing and free Certificates the process to obtain a certificate became cheaper and cheaper and these services grew through out the world and slowly but surely the meaning of a trusted server cert became to have less and less value.

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.

The Hugh Thompson show has been part of the RSA closing for the last 5 years this year one of his closing guests was Alex Conran who has the BBC show "The Real Hustle" demonstrates to the audience just how we are all vulnerable to scams. The examples seems right out of the movie "Match Box Man" were teams of people collaborate on the hustle. One of the talks was still about how keyboard loggers and bank scams still work with an elaborate collection call center sounds and audix messages the user is convinced to enter there pin information on the phone. Even if they are not convinced to provide there information later the key logged host still visits the banking site where the information is sent to the user.

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. Michio Kaku's keynote address at the RSA conference was full of thoughts on what the near future holds for us in the way of technology breakthroughs. Dr. Kaku quoted Woody Allen on eternity, "Eternity is an awful long time, especially near the end." And shared his thoughts on the future of Medicine, in which he states that all medicine will be resolved with computers.

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?

Information Security Governance - Hybrid Security Cloud Provider Services and Security Team Management Collaboration and Trust.

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

In my previous blog posting I defined incident response, described why it is so important, and then presented six of the most serious mistakes in incident response that people and organizations too often make. In this posting I'll cover the rest of these mistakes.

• 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 is generally defined as actions taken to protect and restore the normal operating condition of computers and the information stored in them when an adverse event occurs. The goal is to reduce the impact to a level that is acceptable; senior management must define what acceptable impact levels are. Incidents must be closed and affected systems, applications and databases must be restored within the Acceptable Interruption Window (AIW) for the type of incident that has occurred. Any incident (e.g., a data security breach) that threatens to quickly escalate out of control causing massive financial loss will almost certainly have a much lower AIW than one (e.g., when a single user workstation is infected with spyware) that is less likely to spread quickly with far less financial loss.

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.

netForensics today announced that the company exceeded expectations with MSSP revenues up 50%, resulting in another profitable quarter.  Driven by key strategic relationships and product enhancements netForensics continues their commitment in delivering unparalleled security visibility and maintaining compliant operations for the world's largest Managed Security Providers (MSPs) and Cloud Security Services.  Read more>

Procrastinators never cease to amaze them. They seem to have a ready excuse (no matter how lame) for every inaction and delay. Having taught in universities for many years, I found that procrastination ran high among students. I in particular remember days on which term assignments were due and how so many bedraggled-looking students would come to turn them in and then take a seat and fall asleep. Procrastination does indeed have some serious downsides.

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.