ASK THE EXPERT - INCIDENT MANAGEMENT

Unanswered Question
Oct 19th, 2007

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to get an update on how to have a good Incident Management process to prepare for security threats which have increased dramatically, with Cisco expert Omar Santos. Omar is a senior network security engineer in the worldwide security service practice of Cisco's advanced services for network security. He has more than ten years of experience in secure data communications. He has designed, implemented, and supported numerous secure networks for Fortune 500 companies and the U.S. Government.


Remember to use the rating system to let Omar know if you have received an adequate response.


Omar might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through November 2, 2007. Visit this forum often to view responses to your questions and the questions of other community members.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
Omar Santos Tue, 10/23/2007 - 19:46

A solid patch management strategy is crucial with the rise of widespread worms and

malicious code that targets known vulnerabilities on unpatched systems. This is why the

increasing governance and regulatory compliance enforcement by organizations like HIPAA and Sarbanes-Oxley has pressed organizations hard to gain better control and

oversight of their information assets.

The main objective of a patch management program is to create a consistently configured

environment that is secure against known vulnerabilities in operating system and

application software. Patch management solutions vary in design and implementation.

Regardless, several technology-neutral best practices are listed in this section and can be

followed no matter what patch management software or solution you use.

A good practice is to designate a point person or a team that is responsible for keeping upto-

date on newly released patches and security threats that affect the systems and

applications deployed within your organization. Have a complete and accurate asset

inventory to determine whether all existing systems are accounted for when preparing and

deploying patches and updates.

Also, prioritize and schedule the necessary application patches/updates. A patch update

cycle must exist to facilitate the application of standard patch releases and updates. You can

perform the cycle in a scheduled time fashion or based on events. You can implement the

time-based scheduled cycle weekly, biweekly, or monthly, depending on the organization

policies. In contrast, you can coordinate the scheduling cycle with critical security patches

and updates. This plan should help you deal with the prioritization and scheduling of

updates that must be deployed in a more immediate fashion.

Preferably, you should test patches and updates before deploying them to your systems. In

critical situations when a security patch is needed because of a worm or a security outbreak,

detailed testing may not be possible or feasible. The initial phases of production rollout can

be considered an additional component of the testing process. Rollouts are often

implemented in tiers with the initial tiers often involving less critical systems. Based on the

performance of these stages of the patch deployment process, the entire environment will

be updated, and the testing process can be considered finished with the completion of final

acceptance testing.

Regular audits and assessment help gauge the success and extent of patch management

efforts. You should always determine what systems you need to patch for any given

vulnerability or a bug. In addition, you should always verify that the systems that are

supposed to be updated have been patched.

leon.mflai Tue, 10/23/2007 - 08:36

May I know what Cisco product is related to Incident Management?


BR,L.Lai

Omar Santos Tue, 10/23/2007 - 19:55

Hi,


Incident management is not a product-specific methodology; it is more of a life-cycle. There are many security products and technologies that can be implemented to better prepare your infrastructure. Incident management and incident readiness is beyond the "black box" approach that many people take. For example, you can take advantage of event monitoring and correlation tools such as CS-MARS to quickly monitor, identify, and mitigate a network threat to improve uptime and increase productivity. You can deploy strong security policies on multi-function security devices such as the Cisco ASA to enhance the security of your network.


Just like I mention in my book and other articles... You must also build strong configuration guidelines, policies, and best practices to effectively prepare your organization against security threats. Building strong security policies is crucial for any organization. These policies should be strong, yet realistically flexible to accommodate ever-changing requirements.

dmease Thu, 10/25/2007 - 01:11

Hi,


We have had ongoing problems with a specific signature, namely 'TCP Segment Overwrite', sig 1300/0.

Due to the fact that this should be a rare attack, as it has a low probability of working and is 'difficult', we became suspicious a while back due to the volume, and raised a TAC case 602133293, which ended up with a bug being opened up as the signature fired when nothing was overwritten (something to do with keepalives on certain TCP stacks). This was fixed and all was well for a while, but in later versions of 5 code, this started appearing again.


The problem we have is how we troubleshoot this - we cant log on the sensor as the sensor only starts logging from the packet that caused the alert, so we cant see the packet that was overwritten. has anybody got any ideas of the best way to troubleshoot this, as the only way we can think of is to constantly capture packets on the server (or another sniffer) with wireshark or the like.


I note on the forums there have been a few posts about this, and due to the fact that we manage quite a few sensors, I can confirm that most clients have got so sick of the alert, they have just requested that it is filtered, as they feel they have no other option.


cheers!

Omar Santos Wed, 10/31/2007 - 07:16

Hi,


I have researched the TAC service request you described as well as talked to the engineers that were helping you. Unfortunately, since this was a defect in our code (ie., a bug) the troubleshooting procedure is very particular to these symptoms. Unfortunately, other than the examination of the server packets with a sniffer, just as you mentioned, the sensor will log the packet that caused the alert. Although, you can create more customized rules to capture other packets, it may be simpler and easier to use the sniffer on this case. Again, this is because the nature of this specific problem.

Actions

This Discussion