- Paranoia is good when it comes to cyber-security…or is it?
Are we making ourselves paranoid? Like many computer security professionals, I tend to closely follow technology and security news, even though its often discouraging and depressing. It is routine to see articles disclosing general information about recent attacks and criminal successes (and sometimes criminal captures). I suppose that at this point it is fairly common to find “shocking” breaches of trust and security in major corporations or large, widely-used or well-trusted systems. Even reports of malware infections in drone control centers was met with a certain “well it was only a matter of time” feeling. This cynicism is common amongst those who work in the computer security field, both as reporters and as professionals in some capacity from tier 1 support to penetration testing and CSO’s. When you’re a cynic, you stop being surprised.
What has started to happen as a blowback from all this security bad press and cynisism is a general feeling of paranoia. This paranoia, advocated by security pros to general users in order to cut down the rate of infection of users and lessen security risks, is starting to creep into the minds and actions of security personnel.
This is a major problem because overly-paranoid security team members can cause major headaches with overreactions to abnormal conditions. Like in Illinois with the water pump scare, or with the recent rumours of Iranian spy drone hacking. While computer security problems have plagued us for years, they aren’t always to blame when something unexpected happens. It’s important not to alienate users, customers, and the world at large by overreacting or acting before all the information is gathered.
It’s like the boy who cried wolf. If your security team jumps at nothing all the time, they will not be taken seriously when they need to.
Implement policy to fix announcements of false positives. A simple series of steps and confirmations should be enough to let you detect, learn about, and defeat intrusions.
- Verify with users or other policy that system behaviour is unexpected or unwanted.
- Gather information about activities on system. Running programs, users, log information, communications to other systems, and outbound communications are important to know in order to profile the attack and determine the extent of the damage and action.
- Disable/disarm attacker. Use knowledge gained from step 2 to block attackers when starting remediation/triage.
- Perform triage and remediation procedures on affected systems.
You will need to determine for yourself when along that process a security disclosure needs to occur in order to remain compliant with standards and honest with users/customers.
Related Reading:
McKinsey on Big Data Part 2: Production, Supply, and Logistics
