Responding to Security Incident Threats
Practical advice for keeping security threats in check.
You will be attacked. It may an outsider, but you must also work to mitigate insider threats as well. Insider threats can be deliberate, negligence, or even accidental such as a scenario where an insider device is used by an outsider as a proxy. Wherever the threat originates, you need to be prepared. One of the most surprising observations is that security threats exist for an average of 205 days before they are detected.
It is not unusual that an enterprise is running 500+ apps on its network. Some are cloud based, others are on mobile devices. I have so many passwords; I keep a separate file on them. I re-use passwords to reduce my confusion, but this increases the possibilities of a successful attack.
Insiders have privileges. An insider can be on an outside network, but hackers can also make their attacks look like normal operations. So the enterprise has to implement technical and non-technical measures that the enterprise can use before, during, and after an attack.
Preparing in AdvanceAssets and Connections
The worst position an enterprise staff can take is to assume they are unlikely to be vulnerable. Not true. So preparation is the key to reducing or blocking the incident. When it comes to security, "You don't know what you don't know."
So know thy inventory. There are hundreds, maybe thousands, of assets and connections that are the responsibility of IT, both on internal and external networks like the Internet (users, customers, and social networks) and wireless networks. These assets and connections may be owned by IT, users (BYOD), cloud services, and third parties that are not part of the enterprise. You may be surprised that you do not know the real asset and connection inventory until you start looking for it. This is where the right software tools can be helpful.
Encryption is more than an ounce of prevention. It will at least reduce the possibility that assets like data will be accessible to hackers in storage, while in transit, or when it is being used.People Interacting with Assets and Connections
It would be much easier if the users had a few identifications. Not so. There are MAC and IP addresses, phone numbers, social network IDs and user IDs. The identifier is not the hacker, so associating the IDs with a real person can be difficult especially when users share their IDs and access codes.
Software tools can reduce this problem. Look for identity management systems that can correlate IDs with people and their privileges. Send out a brief listing each week about the attacks your network and assets have encountered to make users aware that security is an ongoing problem.
Tasks during the IncidentMonitoring Access and Use Activity
The goal is to flag suspicious activity. You may not realize how much traffic activity you cannot monitor. Encryption is good, but you may not know what is being transferred. You also need to be able to perform decrypted analysis. Approximately 1/3 of traffic with social media providers, file sharing services, and e-mail use SSL, which limits monitoring. Intrusion prevention systems (IPS) with frequent updates are mandatory.Implement Analytics Collection During the Incident
Collecting information about the operation and condition of IT assets is necessary if you want to perform the analytics after the incident.
You can leverage the collected information using software in addition to the manual analysis by IT staff. There will probably be information that the software does not collect or process exactly the way you want. Collect information from users as well as from IT systems and network. Collect user information ASAP. The affected users may not be available later, or they may have forgotten pertinent information from when the problem occurred.
- Visualize -- Look for tools that produce visual displays of the incident. A visual display may accelerate human perceptions of the incident and help develop conclusions faster.
- Correlate -- Most of the collected information is in pieces. Correlating those pieces together that may seem unrelated can produce conclusions that otherwise would not be evident.
- Watch for Patterns -- There will be normal operation patterns to the use, access, and transfer of data. Look for abnormal patterns, as these may be the beginning of an attack.
- Look for Anomalies -- Look for user behavior that is not common such as accessing and downloading data which the user usually accesses. Unusual behavior does not necessarily mean an attack. On the other hand, it is better to rapidly question the unusual behavior than assume it is acceptable.
Post Incident Analysis
When the attack has stopped or you have blocked it, you should still analyze the collected attack information to ensure that such an attack can be blocked in the future. This analysis is bordering on big data, therefore you should consider big data tools for the security review.
The methods for stopping the attack will have to be reviewed to see if they can be permanently applied. If a user or group of users is the culprits, go back through that user's history to see if there are undetected attacks that need to be blocked in the future. Do not assume that a single attack is unrelated to other attacks. Successful attackers will continue to use successful methods until they are discovered.
I have written about security in many of my previous blogs. To read more, see Who's on Your Network?, IT Security Can Be So Inconvenient..., Security in the Open Office, Security Mistakes: Technology or Behavior?, Cyber Crime Economics, and Hacking Through Back Doors.