Tag Archives: Data Security

How to Respond to a Cyber Security Incident

How to Respond to a Cyber Security Incident

Every day another company is caught off guard by a data breach. While avoiding an attack is ideal, it’s not always possible. There’s no such thing as perfect security. Even if you’ve outsourced your IT or your data lives in the cloud, ultimately the responsibility for keeping your customer data safe falls on your shoulders.

In the unfortunate case that your company suffers a breach, you should be prepared to address it swiftly. To help, we created an easy to implement plan that outlines ways to proactively respond and recover from a cyber security incident.

Avoid

pexels-photo-30267-medium

Avoiding an attack is best whenever possible – but it’s just as important to have a cyber incident response plan in place in anticipation of an attack.

Take Inventory

What information is mission critical to your organization? Where does it live? How quickly can it be reinstated if it’s taken out in an attack?
Perform a complete audit of your systems, take note of the most important components, and track everything . Make sure you are not the only person aware of this document.

Pick a Team (or Two)

Now that you know what is most important, make sure all the relevant players are aware as well. Nominate one person as the IT owner in the event of a cyber attack. This individual needs to be readily available in case of an emergency, and equipped to manage the many internal technical components involved with recovering from a breach.  Nominate a second person to own the management of external needs of a breach – such as outreaching to public relations, getting in touch with the organization legal counsel, etc. Both of these roles are critical for a timely and effective response. Just to be safe – pick a second in command for both teams. After all, no man is an island.

Make a Plan

You know the data, you have the right people in place – now it’s time to develop an actionable plan and provide specific, concrete procedures to follow during a cyber incident. The procedures should address:

  • Who has lead responsibility?
  • How to contact critical personnel, and what data, networks, and services should be prioritized for recovery.
  • How to preserve data that was compromised by the intrusion and perform forensics to review for gaps in security and insights into the actual attack.
  • Who needs to be notified (data owners, customers, or partner companies) if their data or data affecting their networks is stolen.
  • When and what law enforcement will be brought into the picture, as well as any regulated reporting organizations.

Need a little more guidance? The California Department of Technology has a wonderful outline available online that is a great starting point!

Once developed, this plan should NOT live in a bubble. Make sure everyone on the team is aware and has read and reviewed. In addition, take time to appraise the plan every quarter for relevancy and update as necessary. Unfortunately, security is not static. Also, this is important; it should be tested PRIOR to an actual cyber incident. Tornado, zombie apocalypse or biblical flooding is NOT the time for a try-out.

Address

marketing-man-person-communication-medium

Despite all your planning, preparation, and good intentions – what happens if (when) you are struck by a cyber attack? First things first – implement your cyber incident plan as soon as possible. Take a critical assessment of the situation. Does it appear to be a malicious attack or a simple tech glitch or misconfiguration? Once you’ve determined intent (and it’s not good), it’s time to collect and preserve the impacted data, and put the rest of your plan into action.

Who You Gonna Call?

Shhh…it’s not Ghostbusters! You should already have this information in place and readily available in your cyber incident plan. Start your outreach right away and begin with your response owners and work your way down the line. For example, the “external” owner at your organization should notify law enforcement, possible victims and the Department of Homeland Security, if necessary. Overall, the best approach is transparency. No one wants to admit to a breach. However, hiding critical information or delaying notification can backfire. A good approach involves being as direct as possible, highlighting the known and promising a timely follow up on any unknown. As always, keep it simple and straightforward. Don’t make promises you cannot keep or address concerns that are not valid.

You Might Need a Professional

Sometimes an internal response team just isn’t enough. Fortunately, there are many third-party organizations that specialize in incident response and can help you navigate through the breach. The fresh set of eyes can look at the breach in a way internal staff – already vested in the company and outcome – cannot. They can help you discover exactly what has been accessed and compromised, identify what vulnerabilities caused the data breach, and re-mediate so the issue doesn’t happen again.

Verify, then Reinstate

Finally, verify that your backup data was NOT compromised. It would be “no es bueno” to restore your system using data that you believe is valid, only to discover that your backup was just as bad as your compromised data.

Action

people-new-york-train-crowd-medium

Even after a cyber incident appears to be under control, remain vigilant. Many intruders return and attempt to regain access to networks that they previously compromised. It’s possible that, despite your best efforts, a hacker could STILL find a way into your system. They are a slick, determined bunch.

Monitor & More

Continue to monitor your system for out of the ordinary activity. Invest in a software solution that utilizes User Behavior Analytics to recognize unusual behavior and notify prior to an actual attack. Varonis, for instance, will recognize and notify about both external and internal threats before irreparable damage can be done.

Just the Facts Ma’am

Once your organization has recovered from the attack, it’s time to thoroughly review what happened, and take steps to prevent similar attacks. What went well with the cyber incident response plan? What may need just a wee bit of tweaking? Assess the strengths and weaknesses of the plan, and determine what needs adjusting. Implement the changes. You’ll be glad you did if (when) you are attacked again.

React, Revise & Revisit

Protecting against a cyber incident is a full-time job. As ransomware evolves and the insider becomes a consistent threat, it’s important to continuously revise and revisit your Cyber Incident Response plan:

  • Keep your plan up to date.
  •  Have the right technology in place (including lawful network monitoring) to address an incident.
  • Hire legal counsel that is familiar with the complex issues associated with cyber incidents.
  • Make sure existing corporate policies align with your incident response plan.

A cyber incident is never something you want to face. However, being proactive and prepared will make a huge difference in your response.

Introduction to OAuth (in Plain English)

OAuth

We’ve talked about giving away your passwords and how you should never do it.  When a website wants to use the services of another—such as Bitly posting to your Twitter stream—instead of asking you to share your password, they should use OAuth instead.

OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.

This is a quick guide to illustrate, as simply as possible, how OAuth works.

The OAuth Flow

There are 3 main players in an OAuth transaction: the user, the consumer, and the service provider.  This triumvirate has been affectionately deemed the OAuth Love Triangle.

In our example, Joe is the user, Bitly is the consumer, and Twitter is the service provided who controls Joe’s secure resource (his Twitter stream).  Joe would like Bitly to be able to post shortened links to his stream.  Here’s how it works:

Step 1 – The User Shows Intent

Joe (User): “Hey, Bitly, I would like you to be able to post links directly to my Twitter stream.”
Bitly (Consumer): “Great! Let me go ask for permission.”

Step 2 – The Consumer Gets Permission

Bitly: “I have a user that would like me to post to his stream. Can I have a request token?”
Twitter (Service Provider): “Sure.  Here’s a token and a secret.”

The secret is used to prevent request forgery.  The consumer uses the secret to sign each request so that the service provider can verify it is actually coming from the consumer application.

Step 3 – The User Is Redirected to the Service Provider

Bitly: “OK, Joe.  I’m sending you over to Twitter so you can approve.  Take this token with you.”
Joe: “OK!”

<Bitly directs Joe to Twitter for authorization>

This is the scary part. If Bitly were super-shady Evil Co. it could pop up a window that looked like Twitter but was really phishing for your username and password.  Always be sure to verify that the URL you’re directed to is actually the service provider (Twitter, in this case).

Step 4 – The User Gives Permission

Joe: “Twitter, I’d like to authorize this request token that Bitly gave me.”
Twitter: “OK, just to be sure, you want to authorize Bitly to do X, Y, and Z with your Twitter account?”
Joe: “Yes!”
Twitter: “OK, you can go back to Bitly and tell them they have permission to use their request token.”

Twitter marks the request token as “good-to-go,” so when the consumer requests access, it will be accepted (so long as it’s signed using their shared secret).

Step 5 – The Consumer Obtains an Access Token

Bitly: “Twitter, can I exchange this request token for an access token?”
Twitter: “Sure.  Here’s your access token and secret.”

Step 6 – The Consumer Accesses the Protected Resource

Bitly: “I’d like to post this link to Joe’s stream.  Here’s my access token!”
Twitter: “Done!”

Recap

In our scenario, Joe never had to share his Twitter credentials with Bitly.  He simply delegated access using OAuth in a secure manner.  At any time, Joe can login to Twitter and review the access he has granted and revoke tokens for specific applications without affecting others.  OAuth also allows for granular permission levels.  You can give Bitly the right to post to your Twitter account, but restrict LinkedIn to read-only access.

OAuth Isn’t Perfect…Yet

OAuth is a solid solution for browser based applications and is a huge improvement over HTTP basic authentication.  However, there are limitations, specifically with OAuth 1.0, that make it far less secure and less user-friendly in native and mobile applications.

OAuth 2.0 is a newer, more secure version of the protocol which introduces different “flows” for web, mobile, and desktop applications.  It also has the notion of token expiration (similar to cookie expiration), requires SSL, and reduces the complexity for developers by no longer requiring signing.

Other Resources

Hopefully this was a good primer to get you familiar with OAuth so the next time you see “Sign-in with Twitter” or similar delegated identity verification, you’ll have a good idea of what is going on.

If you want to dive deeper in into the mechanics of OAuth, here are some helpful links: