When catastrophic incidents involving aircraft or trains take place in the United States, the National Transportation Safety Board or NTSB, assembles a team, coordinates the investigation, and publishes a report.
NTSB reports include the factors that contributed to the incident and recommendations that may prevent or reduce the impact from future incidents.
There is no cyber equivalent of the NTSB (yet), but we can look at the NTSB’s example and apply a similar process to strengthen an organization’s posture before an incident takes place.
If your organization has yet to settle on a cyber security strategy or is in the early stages of operationalizing a strategy, this article offers a perspective gained from research and experience into incidents and their causes. Nothing will stop all cyber incidents, but attention to these areas can reduce the chances of a successful attack.
Don’t let an incident go to waste. Learn from incidents that have taken place in other organizations.
Nearly every week at least one incident will make the news. It is helpful to map the details of the incident to your organization’s environment, especially when the incident takes place within your industry or one closely related. Though the initial reports about the incident may not contain many details, it’s often possible to generalize what has been published, so it can be made relevant and useful to your environment.
VerSprite has worked with organizations where this type of exercise was done on a monthly or quarterly basis. These reviews took the form of a discussion and typically lasted an hour or two. Members of cybersecurity, information technology and other groups from inside or outside the organization were invited depending on the events described in the articles.
One additional side benefit of these discussions was that it helped different teams who may not always have the chance to work closely with each other get to know others within the organization. This improved collaboration and response times when events were detected that needed additional triage or action.
Don’t let your organization’s own events, near incidents, or actual incidents go to waste. Breach reports segmented by industry are great as they provide an outside perspective than can be used as a rough benchmark for your environment. Your organization’s incidents or events may be used to make comparisons with others in the industry and provide a rough measure of where your organization stands.
Your ticketing system may be another valuable source of overlooked information. While some events may have a clear relationship to security, other events may require a bit more analysis. Events with no immediate or clear connection to security may be early indicators that contribute to security incidents.
Based on the information available from published breach studies, at least 90% of incidents start with an email. The email may attempt to collect credentials, or it may contain an attachment or link that is malicious and ultimately leads to a compromise. Email attacks are among the easiest to use and are often driven by the time of year and high-profile events.
Tax season is popular as attackers attempt to gather W2s for use when filing fraudulent tax returns. Natural disasters, celebrity deaths, or other well publicized events, especially those that have a significant emotional aspect, are all popular with attackers that understand compromising the human often leads to compromising the environment.
Using a robust two-factor or multi-factor authentication solution with email makes it more difficult for the attacker to harvest credentials. Two-factor authentication is not a cure all to prevent account takeover, but for many organizations, it will make the attacker move on to easier targets.
Microsoft recently stated that a significant number of successful attacks took place against systems that were unpatched even though a patch had been available for months. Media accounts, industry studies, and reports provide examples and insight on organizations that have failed to deploy patches in a timely fashion.
Patching presents challenges for many organizations, and the lack of an effective approach has put many organizations in the position of having to make breach announcements, which if not handled effectively, makes an already bad situation, worse. The most mature organizations will be able to rate, test, track, audit and report on patch deployments.
Organizations that are in the early stages of the threat management lifecycle may not be able to operate each of the stages and should develop, at a bare minimum, the capability to audit installed software and then combine that information with the role of the system to form the basis of a patching strategy.
Use some form of anti-virus or anti-malware technology on endpoints. While the effectiveness of traditional anti-virus software may be debated, there are other technologies that fall into the broader anti-malware category that have expanded on conventional anti-virus methods.
Traditional anti-virus software may not fully stop malware, but it often generates alerts or other signals that hint at emerging problems. When alerts are centrally managed and reviewed, it becomes possible to spot patterns and focus resources on areas that may be under active attack.
Logging presents several challenges for many organizations. Often logs are not enabled or configured to capture information that supports investigations. When logs are available, often they are not centrally collected, have never been reviewed, and they have a very brief retention period.
If an environment is breached by an attacker and the intrusion isn’t detected and managed quickly, data suggests the attackers will be able to avoid detection for at least six months on average. As unbelievable as a six-month dwell time sounds, the time required to detect an attack has actually been improving for the past few years!
When developing a logging strategy, at a minimum, enable logs and plan to keep them for six to twelve months. Review the contents of the logs and look for dates, times, IP addresses, and usernames, or a description of the activity. When an organization suffers a breach, incident response teams will use whatever logs are available to scope and monitor the response process.
This article has only skimmed the surface on several topics that deserve more attention. Over the next several weeks, we will expand on these topics and address the economics and psychology of cyber attacks, attack disruption, and logging fundamentals.