logo

Mistakes vs. Social Engineering: Two kinds of suffering, one method

Posted by Marbenz Antonio on July 18, 2022

What is Software Piracy? - Panda Security Mediacenter

There are an infinite number of ways for bad things to happen to your data and accounts. For example, someone may inadvertently publish their AWS access keys to GitHub, allowing attackers to easily rack up $100,000 in charges mining cryptocurrencies on expensive GPU-enabled machines. Or “account support” phones with a message claiming your account contains ridiculous charges, but they can be removed after your credit card information is verified. Fake software upgrades exist that steal bank account information. Not to mention account information leaked from one of your online services, including your banking site, sent to your work email with a link to “log in and verify access.” Although there are many reasons for account disclosure, they can be divided into two categories: intentional intent and unexpected leakage.

The one you generally hear about in the press and from service providers is malicious intent. Account databases are compromised, phishing emails fool users into disclosing personal information, and phony “service” calls claim your computer is infected. Almost often, the goal is to separate you from your money. They want your bank account information to transfer money or your credit card information to purchase products such as gift cards, which is a common way for stolen money to be cleaned.

Accidental leaks, or “oops,” as detailed in Red Hat’s Security Detail episode on insider risks, have similar impacts to intentional attacks but are caused by entirely unrelated factors. The most typical “oops” are commits to public code repositories, but they can also be an inadvertent email, a faulty paste into chat, or any other method a perfectly genuine person accidentally places their data somewhere it shouldn’t be.

Both causes rely on someone granting access to their data, but the distinction is entirely in the purpose.

5 Steps for Handling a Data Exposure

However, the overall procedure for dealing with all of these occurrences is the same, and you may even apply these processes in your personal life to plan for and respond to incidents involving exposed data. These are the steps:

  1. Have a plan

  2. Scope the problem

  3. Stop the bleeding

  4. Recover

  5. Take steps to prevent future problems

Let’s look at two examples, one personal and one business, to understand how this strategy works.

Mitigating a malicious exposure

A “support specialist” purporting to be from your credit card provider calls and obtains your credit card number or a company that stores your card is hacked and your card is exposed.

  1. Have a plan: Understand which websites save your credit card for purposes such as recurring payments. This list can be kept in a spreadsheet or scrawled on a piece of paper. This is the list of companies you should contact if something horrible happens.
  2. Scope the problem: Have you had any charges on your account? Will anything important fail if you report the stolen card?
  3. Stop the bleeding: Call the credit card company, challenge any suspicious charges, and obtain a new card number.
  4. Recover: Go through your list of card storage companies and have them replace your old card with the new card.
  5. Take steps to prevent future problems: Some banks allow you to generate temporary or limited-use card numbers, allowing you to minimize the impact of service is compromised. You can also create notifications for your credit card charges, which will help you identify a compromise early. Set up alerts on sites like HaveIBeenPwned to notify you if important personal information is leaked.

Many people have probably dealt with this previously, and it all sounds rather regular. When awful things happen, the procedure of dealing with leaks is primarily common sense and not panicking.

Addressing an accidental exposure

You’re working on a project that creates and manages cloud instances automatically. You ‘git adds’ your credentials to the repo in haste and push them to your public source. A few hours later, one of your coworkers finds the credentials in the source.

  1. Have a plan: You should know who to contact on your security team. They can offer support and next steps, as well as contacts to help with more advanced analysis and mitigation. In the absence of such a team, make sure you know who has access to update and alter credentials and who to contact in an emergency (such as your cloud provider technical account manager, support email address, and so forth). Also, be aware of which services use your credentials. Where are your services functioning, and who is in charge of them?
  2. Scope of the problem: Did the credentials enable the creation of accounts or only instances? Which cloud service provider was it? These (and maybe other) questions must be answered to identify the extent of the problem.
  3. Stop the bleeding: Disable the credentials with your cloud provider right away. Many attackers will use the keys to generate their keys, so looking for any unusual keys in the account or any unknown instances running can help stop the bleeding. After the keys have been revoked, the next step is to look for any unexpected occurrences in all regions to stop the spending. Make a note of whatever you discover, and follow your security team’s advice as to whether the instances should be entirely terminated or simply paused for future forensics.
  4. Recover: Push new credentials to all users and service accounts and validate that they are operational. Take whatever efforts are needed to clean up the area and you may be eligible for a discount on any expenses the assailants acquire. You should also use a tool like BFG Repo-Cleaner to delete the unwanted commits. If multiple individuals contribute to a repo, its members may need to coordinate, so read the guidelines carefully.
  5. Take steps to prevent future problems: This is where you can do a lot to avoid it from happening again.
    • First, keep configuration files out of sources. This is accomplished with Git by including a gitignore file in the source. Collaborate with your team to standardize the name of config files and other sensitive objects, and add new repositories to your gitignore files. This can avoid a variety of “oops” incidents!
    • Second, search for tools like Gitleaks to run against your repositories regularly to look for sensitive material. This can uncover secrets, certificate keys, and other sensitive data. You can also use gitleaks as a pre-commit hook to prevent sensitive items from being uploaded to the source, even if they are outside files in gitignore.
    • Finally, ensure that everyone is aware of the strategy and who to contact in an emergency. Whatever the size of your team, having a plan of action in place is important in a crisis to avoid a downhill slide of damage.

Defend against data exposure

The main difference between these two catastrophes is how they are prevented. Social engineering takes advantage of our desire to help and our natural trust in persons who appear to be informed. Defending against this requires primary training and critical thinking, as well as instruments such as spam-blocking software and well-defined protocols to protect us from giving out the information we shouldn’t.

The failure to have systems in place to assist catch the mistakes that we all make magnifies “oops” incidents. You can train people and provide them with protocols, but it’s all too simple for them to make a costly mistake that costs tens or hundreds of thousands of dollars. The objective is to give developers a “safe base” that can assist avert a little problem from becoming a big disaster.

 


Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com

Verified by MonsterInsights