Being information security professionals, we have obligation to follow good e-mail practice, by this we can operate with due care in our profession and that will make us look good. In my earlier job, colleague of mine [a security expert] had sent me an e-mail describing how he broke the weak encryption of an application. Inadvertantly, in his e-mail, he had pasted his own encrypted password! I showed up at his office and presented this expert his own password. All I did was to follow his advice and write a trivial program to break the cipher. It is very important that we as security professionals should not  look or act stupid ;)

Check out this blog post from Marshall Goldsmith  "E-Mail Food for Thought". Excerpt from this blog:

"Managers need to worry not just about their own e-mail but also that of their employees. Email is permanent and searchable and can be forwarded as easily to a thousand people as to just one. And the results can range from embarrassing to costly to disastrous. All the goodwill you've built up over years or decades can be destroyed with one bad e-mail from anyone in your organization."

At the risk of sounding like a preacher, I would like to share this short story.   Many of us, ACT only when bad news hits the roof and  at the point we don’t ACT pragmatically since we did not plan for it!  We recently attended a friend’s daughter’s birthday party. Before heading to the party, I printed out the driving directions from the Internet. hit the freeway in the south direction, when the exit arrived found that the exit ramp was closed for repairs.  Using common sense, I traveled further south, and took another exit to head North on the same freeway, the exit arrived, but this was blocked too! We did not know how to get to the party and the cake cutting time was approaching. What are my plans for this incident? Luckily I had an AAA map in my glove compartment and I found our way right on time to the cake cutting time. In future I decided wherever I go I have to carry maps or buy a GPS or as a last option ask around.

Security incidents are sometimes a blessing in disguise. It compels you to act. There is a tendency among upper management to blame security team for security incidents.  Knee jerk reactions such as CIO firing the CSO or the CSO firing the security team members should be avoided. The facts around the event should be enumerated and the incident should be dealt with pragmatically  [refer Pragmatic CSO: Step #8 Contain the Problem]. Security incidents are  “breakdowns”.  When there is a nasty security incidents here are some facts:

1. There is a business cost associated with the incident.
2. There is a vulnerability that has been exploited by a threat agent.
3. The vulnerability could be:
• Unknown
• Known but accepted
• Known but Ignored
4. The incident needs to be handled with due care.
5. Either you have a well defined incident handling plan or you are shooting from your hips [remember P-CSO The Incident Playbook] .

Scenario 1: The vulnerability that resulted in the incident was known and was accepted. Remediation: Deal with the incident and then re-visit the rationale of why this was accepted in the first place.  This highlights the importance of documentation such as business risk acceptance form; this will help to cover your rear during security incidents. Make sure to get a business risk acceptance form signed by the business owner.  An example is a business owner signs a business risk acceptance form if there is no budget to mitigate the vulnerability.

Scenario 2: The vulnerability that resulted in the incident was an unknown. Remediation:  Deal with the incident and create a mitigation plan for this newly known vulnerability going forward.

Scenario 3: The vulnerability that resulted in the incident was ignored. Remediation: Deal with the incident and revisit why the vulnerability was chosen to be ignored in the first place.  It may be possible that you end up making a decision of not ignoring this vulnerability.

In all the above scenarios you have to deal with the security incident, this emphasizes the importance of a sound incident handling plan.  Putting an incident handling plan is fairly simple. Document what you need to do and whom to escalate to, then communicate the incident management plan to the relevant actors and stick to plan when incident does happen.

Here is simple example of what needs to be done for an Earthquake incident:

-             Identify a structurally safe place inside the home to take shelter or identify an open safe place near your house where you can rush

-             Decide on a family meeting place, where all family members get together

-             Enough food for a week

-             Two dozen water bottles etc...