PC PORTAL

Experienced. Trusted. Solutions.

Business + Partners

By

6 Steps to Build an Incident Response Plan

Reading Time: ~4 min.

According to the Identity Theft Research Center, 2017 saw 1,579 data breaches—a record high, and an almost 45 percent increase from the previous year. Like many IT service providers, you’re probably getting desensitized to statistics like this. But you still have to face facts: organizations will experience a security incident sooner or later. What’s important is that you are prepared so that the impact doesn’t harm your customers or disrupt their business.

Although, there’s a new element that organizations—both large and small—have to worry about: the “what.” What will happen when I get hacked? What information will be stolen or exposed? What will the consequences look like?

While definitive answers to these questions are tough to pin down, the best way to survive a data breach is to preemptively build and implement an incident response plan. An incident response plan is a detailed document that helps organizations respond to and recover from potential—and, in some cases, inevitable—security incidents. As small- and medium-sized businesses turn to managed services providers (MSPs) like you for protection and guidance, use these six steps to build a solid incident response plan to ensure your clients can handle a breach quickly, efficiently, and with minimal damage.

Step 1: Prepare

The first phase of building an incident response plan is to define, analyze, identify, and prepare. How will your client define a security incident? For example, is an attempted attack an incident, or does the attacker need to be successful to warrant response? Next, analyze the company’s IT environment and determine which system components, services, and applications are the most critical to maintaining operations in the event of the incident you’ve defined. Similarly, identify what essential data will need to be protected in the event of an incident. What data exists and where is it stored? What’s its value, both to the business and to a potential intruder? When you understand the various layers and nuances of importance to your client’s IT systems, you will be better suited to prepare a templatized response plan so that data can be quickly recovered.

Treat the preparation phase as a risk assessment. Be realistic about the potential weak points within the client’s systems; any component that has the potential for failure needs to be addressed. By performing this assessment early on, you’ll ensure these systems are maintained and protected, and be able to allocate the necessary resources for response, both staff and equipment—which brings us to our next step.

Step 2: Build a Response Team

Now it’s time to assemble a response team—a group of specialists within your and/or your clients’ business. This team comprises the key people who will work to mitigate the immediate issues concerning a data breach, protecting the elements you’ve identified in step one, and responding to any consequences that spiral out of such an incident.

As an MSP, one of your key functions will sit between the technical aspects of incident resolution and communication between other partners. In an effort to be the virtual CISO (vCISO) for your clients’ businesses, you’ll likely play the role of Incident Response Manager who will oversee and coordinate the response from a technical and procedural perspective.

Pro Tip: For a list of internal and external members needed on a client’s incident response team, check out this in-depth guide.

Step 3: Outline Response Requirements and Resolution Times

From the team you assembled in step two, each member will play a role in detecting, responding, mitigating damage, and resolving the incident within a set time frame. These response and resolution times may vary depending on the type of incident and its level of severity. Regardless, you’ll want to establish these time frames up front to ensure everyone is on the same page.

Ask your clients: “What will we need to contain a breach in the short term and long term? How long can you afford to be out of commission?” The answers to these questions will help you outline the specific requirements and time frame required to respond to and resolve a security incident.

If you want to take this a step further, you can create quick response guides that outline the team’s required actions and associated response times. Document what steps need to be taken to correct the damage and to restore your clients’ systems to full operation in a timely manner. If you choose to provide these guides, we suggest printing them out for your clients in case of a complete network or systems failure.

Step 4: Establish a Disaster Recovery Strategy

When all else fails, you need a plan for disaster recovery. This is the process of restoring and returning affected systems, devices, and data back onto your client’s business environment.

A reliable backup and disaster recovery (BDR) solution can help maximize your clients’ chances of surviving a breach by enabling frequent backups and recovery processes to mitigate data loss and future damage. Planning for disaster recovery in an incident response plan can ensure a quick and optimal recovery point, while allowing you to troubleshoot issues and prevent them from occurring again. Not every security incident will lead to a disaster recovery scenario, but it’s certainly a good idea to have a BDR solution in place if it’s needed.

Step 5: Run a Fire Drill

Once you’ve completed these first four steps of building an incident response plan, it’s vital that you test it. Put your team through a practice “fire drill.” When your drill (or incident) kicks off, your communications tree should go into effect, starting with notifying the PR, legal, executive leadership, and other teams that there is an incident in play. As it progresses, the incident response manager will make periodic reports to the entire group of stakeholders to establish how you will notify your customers, regulators, partners, and law enforcement, if necessary. Remember that, depending on the client’s industry, notifying the authorities and/or forensics activities may be a legal requirement. It’s important that the response team takes this seriously, because it will help you identify what works and which areas need improvement to optimize your plan for a real scenario.

Step 6: Plan for Debriefing

Lastly, you should come full circle with a debriefing. During a real security incident, this step should focus on dealing with the aftermath and identifying areas for continuous improvement. Take is this opportunity for your team to tackle items such as filling out an incident report, completing a gap analysis with the full team,  and keeping tabs on post-incident activity.

No company wants to go through a data breach, but it’s essential to plan for one. With these six steps, you and your clients will be well-equipped to face disaster, handle it when it happens, and learn all that you can to adapt for the future.

The post 6 Steps to Build an Incident Response Plan appeared first on Webroot Blog.

By

DNS Protection Gets Major Updates

Reading Time: ~1 min.

Our most recent release of the DNS Protection agent provided customers with added features and enhancements designed to improve the overall product experience and its capabilities delivered to end users. We revamped the network detection functionality to improve accuracy and speed for roaming and off-site clients who frequently change networks.

We also addressed a variety of small bug fixes and performance improvements, such as SSL certification installation on Firefox Quantum and improvements to the agent update process.

VPN & TCP support

The Webroot DNS Protection agent now supports Juno Pulse Secure v 3.5 and Private Internet Access (client version 7.5) VPN types. This new feature enables roaming clients to access intranet assets and ensure clients benefit from DNS Protection while using a VPN.

Additionally, we added TCP Traffic support filtering. While the majority of DNS traffic is handled via UDP, certain domains and applications only use TCP. This update allows the agent to filter both UDP and TCP traffic.

Policy Configuration

We have also enhanced policy configuration with more granular policy control.  Custom policy configurations can now be applied to groups, sites, individual devices or network IP.  We’re also working to improve internet usage visibility, and are excited to make our Top Active Report available for .csv export so it can be easily integrated into other reporting tools in use.

Finally, we’re updating the GSM console to give users the availability to initiate trials and/or purchase products directly within the console.

The post DNS Protection Gets Major Updates appeared first on Webroot Blog.

By

RSAC 2018: “Clearing A Path for More Conversation and Context”

Reading Time: ~2 min.

Two big trends stood out at RSAC 2018. Many organizations that once thought all threat intelligence was created equal have gained appreciation for quality data feeds that deliver real-time information vs. crowdsourced or static lists. Endless alerts and flashy numbers are no longer enough. Companies want to know the “why?” and “what actions they can take?”

“What this tells me is that Webroot is in the right place at the right time with the best solution, and that is a great place to be,” said Michael Neiswender, vice president, embedded security sales.

The subtle messages of small-to-medium businesses (SMBs) and managed service providers (MSPs) demanding a certain focus didn’t fall on deaf ears. The question asked over and over was “how do you get into the SMB space?” There was a clear understanding that it’s a hot market, hard to penetrate, and has specific needs. SMBs require solutions architected from the ground up for multitenancy, high efficiency, and ease of use—customer experience cannot be neglected.

David Dufour, vice president, engineering said, “MSPs are a big business. A lot of people are aware of it, but they don’t know how to attract that market. We’re in a really good position as a company because we understand them.”

Big Conversations

As Webroot spoke with industry peers during the four-day cybersecurity conference, the conversations led to a few more themes.

Real Threat Intelligence is King

Security professionals have a desire for real-time, quality threat intelligence. They are looking for insights that draw from multi-geo, -device, and -businesses. How the updates are delivered to the customer is also of importance. The reality is the scale of threats and the associated risks facing organizations is increasing at a rate companies are finding difficult to manage.

Security is Everyone’s Responsibility

The idea of inherent security will become more mainstream. All companies will have to start thinking and acting like security companies, putting user education first. Loosely handling personal data is no longer an option. GDPR will make sure of that. Simple: your weakest link can be your strongest defense if properly trained.

Getting Back to Basics

Fundamental concepts of cybersecurity are as relevant as ever. The basics at their core address security as a requirement for businesses today in our connected environment. To be effective using cybersecurity start by following the basic fundamental concepts of protect, detect, respond, recover, and user training.

Into the Future

Threat intelligence will continue to offer a powerful position for those who choose to listen to the industry. As Webroot prepares for greater growth in the coming months and years, we are uniquely positioned for the future. You can expect more threat intelligence insights via our Annual Threat Report and Quarterly Threat Trends; continued investigation into our partners’ needs; and solutions that will meet partners where they are.

More companies will realize their customers want them to look at them in a new light. They will also begin to ask the right questions to provide solutions that uniquely address the concerns security professionals have when building their own internal security programs.

“There were companies that I could tell had methodically built out platforms to address specific threats,” said Gary Hayslip, chief information security officer. “These vendors differed from their competitors, because they knew what issues to solve and their technologies were uniquely focused on providing value by integrating with broader platforms to manage risk.”

The post RSAC 2018: “Clearing A Path for More Conversation and Context” appeared first on Webroot Blog.

By

Re-Thinking ‘Patch and Pray’

Reading Time: ~3 min.

When WannaCry ransomware spread throughout the world last year by exploiting vulnerabilities for which there were patches, we security “pundits” stepped up the call to patch, as we always do. In a post on LinkedIn Greg Thompson, Vice President of Global Operational Risk & Governance at Scotiabank expressed his frustration with the status quo.

Greg isn’t wrong. Deploying patches in an enterprise department requires extensive testing prior to roll out. However, most of us can patch pretty quickly after an announced patch is made available. And we should do it!

There is a much larger issue here, though. A vulnerability can be known to attackers but not to the general public. Managing and controlling vulnerabilities means that we need to prevent the successful exploitation of a vulnerability from doing serious harm. We also need to prevent exploits from arriving at a victim’s machine as a layer of defense. We need a layered approach that does not include a single point of failure–patching.

A Layered Approach

First off, implementing a security awareness training program can help prevent successful phishing attacks from occurring in the first place. The 2017 Verizon Data Breach Investigations Report indicated that 66% of data breaches started with a malicious attachment in an email—i.e. phishing. Properly trained employees are far less likely to open attachments or click on links from phishing email. I like to say that the most effective antimalware product is the one used by the best educated employees.

In order to help prevent malware from getting to the users to begin with, we use reputation systems. If almost everything coming from http://www.yyy.zzz is malicious, we can block the entire domain. If much of everything coming from an IP address in a legitimate domain is bad, then we can block the IP address. URLs can be blocked based upon a number of attributes, including the actual structure of the URL. Some malware will make it past any reputation system, and past users. This is where controlling and managing vulnerabilities comes into play.

The vulnerability itself does no damage. The exploit does no damage. It is the payload that causes all of the harm. If we can contain the effects of the payload then we are rethinking how we control and manage vulnerabilities. We no longer have to allow patches (still essential) to be a single point of failure.

Outside of offering detection and blocking of malicious files, it is important to stop execution of malware at runtime by monitoring what it’s trying to do. We also log each action the malware performs. When a piece of malware does get past runtime blocking, we can roll back all of the systems changes. This is important. Simply removing malware can result in system instability. Precision rollback can be the difference between business continuity and costly downtime.

Some malware will nevertheless make it onto a system and successfully execute. It’s at this point we observe what the payload is about to do. For example, malware that tries to steal usernames and passwords is identified by the Webroot ID shield. There are behaviors that virtually all keyloggers use, and Webroot ID Shield is able to intercept the request for credentials and returns no data at all. Webroot needn’t have seen the file previously to be able to protect against it. Even when the user is tricked into entering their credentials, the trojan will not receive them.

There is one essential final step. You need to have offline data backups. The damage ransomware does is no different than the damage done by a hard drive crash. Typically, cloud storage is the easiest way to automate and maintain secure backups of your data.

Greg is right. We can no longer allow patches to be a single point of failure. But patching is still a critical part of your defensive strategy. New technology augments patching, it does not replace it and will not for the foreseeable future.

The post Re-Thinking ‘Patch and Pray’ appeared first on Webroot Blog.