PICERL, or Life is a Series of Incidents:
- Preparation: Gather and learn the necessary tools, become familiar with your environment.
- Identification: Detect the incident, determine its scope, and involve the appropriate parties.
- Containment: Contain the incident to minimize its effect on neighboring IT resources.
- Eradication: Eliminate compromise artifacts, if necessary, on the path to recovery.
- Recovery: Restore the system to normal operations, possibly via reinstall or backup.
- Wrap-up (or Lessons Learned): Document the incident’s details, retail collected data, and discuss lessons learned.
Start with threat analysis.
- Understand what the threats are.
- Identify critical assets.
- Identify the vulnerabilities of these assets.
- Identify the risks plotted against likelihood and severity.
- For your high risk items, identify cost effective measures.
- Validate your results.
- Present your findings.
- Implement measures.
- Go back to the top, reanalyze why your situation changes and represent the facts.
Do the right thing. Sometimes you have trouble determining what the right thing is. Often the decision is based upon costs and benefits. This method works in many cases. But consider two-factor authentication and online banking: it is expensive to implement two-factor authentication. Losses occur when accounts are hacked. These losses can be estimated. The cost of two-factor authentication exceeds the costs of incidents. Therefore, two-factor authentication is not implemented.
Should that be the appropriate decision-making process? It does not take into account the distress of depositors whose accounts are breached. It does not take into account lost reputation and ill will. These can be assigned values and the cost-benefit formula is recomputed. Perhaps two-factor authentication turns out to be less expensive. Have you decided to do the right thing because you have fudged the numbers to produce the desired result? Perhaps two-factor authentication should be considered the right thing to do, and the equation relegated to a supplemental role. It is, after all, an ethical decision we are making. Efforts to produce an ethical calculus are doomed to failure. Nonetheless, we should still make computations to clarify our assumptions.
A list, by category, with techniques in order of “importance.”
Firewall (inbound packets)
|Firewall (inbound packets, layer 3)
Firewall (stateful, layer 7)
Intrusion Prevention System (IPS)
Firewall (source blacklist, layer 3)
Network Access Control (NAC)
|Detection||Intrusion Detection System (IDS)||Intrusion Detection System (IDS)
Firewall (destination blacklist, layer 3)
DNS lookup history
|Recovery||Anti-Virus||Rebuild, Reimage, Restore|
Obscurity: Security through obscurity is one of your defenses, just not a very reliable one.
Network Access Control (NAC): listed as “Now” but probably should be in a “future” column.
Firewall: General term for “mechanism to drop network traffic.” Drop network traffic you do not intend to manage. (Note about SPAM: Drop email you do not intend to manage.) For example, drop unsolicited network traffic (which means “monitor state”).
Anti-Virus: Note the changed role of Anti-Virus. Its role in Prevention is tarnished; its role is Recovery is diminished, but its role in Detection is significant. Not “dead“.
Blacklist: resolve names to an actual destination, not the loopback address (127.0.0.1). You’ll get to log the connection attempts. You won’t have the additional name resolution requests that occur with the loopback address.
As for an IDS … interesting story. How does one learn that their preventative measures have been insufficient, and that an intrusion has occurred? How does intrusion detection take place? We spent a great deal of money on network equipment to detect an intrusion based upon anomalous network traffic. You feel pretty good about that investment when you finally find something. You feel pretty disappointed with that investment when your incident response investigation reveals that you should have been aware of that intrusion long ago. Your anti-virus software detected malware, but no one followed up to find the undetected malware that was installed at the same time. I would still keep an IDS around (and keep its signatures up-to-date), but it is relegated to an auditing role, giving us the ability to tell management that we aren’t seeing that traffic, the threat that made the news, on our network.
When I hear “you’re lucky you weren’t hit with the blah-blah-blah attack…” luck had nothing to do with it. There’s no glory for being the person who works with ant-virus log events, using the information to shore up the Intrusion Prevention System (IPS) and feed undetected malware back to vendors. No glory, its just effective.
“Information extrusion”? Could be detecting information leakage, even over encrypted network connections (e.g., Blue Coat SG). Control through document management systems, such as egress.
Recovery: Does not address what has been disclosed.
Microsoft Whitepaper Mitigating Software Vulnerabilities