10 Most Common Web Security Vulnerabilities.

 

OWASP or Open Web Security Project is a non-profit charitable organization focused on improving the security of software and web applications.

The organization publishes a list of top web security vulnerabilities based on the data from various security organizations.

The web security vulnerabilities are prioritized depending on exploitability, detectability and impact on software.

• Exploitability –

  What is needed to exploit the security vulnerability? Highest exploitability when the attack needs only web browser and lowest being advanced programming and tools.

• Detectability –

  How easy is it to detect the threat? Highest being the information displayed on URL, Form or Error message and lowest being source code.

• Impact or Damage –

  How much damage will be done if the security vulnerability is exposed or attacked? Highest being complete system crash and lowest being nothing at all.

  The main aim of OWASP Top 10 is to educate the developers, designers, managers, architects and organizations about the most important security vulnerabilities.

  The Top 10 security vulnerabilities as per OWASP Top 10 are:

• SQL Injection
  
• Cross Site Scripting
  
• Broken Authentication and session management
  
• Insecure Direct Object References
  
• Cross Site Request Forgery
  
• Security Misconfiguration
  
• Insecure Cryptographic Storage
  
• Failure to Restrict URL access
  
• Insufficient Transport Layer Protection
  
• Unvalidated Redirects and Forwards
  

 

SQL Injection.

Injection is a security vulnerability that allows an attacker to alter backend SQL statements by manipulating the user supplied data.

Injection occurs when the user input is sent to an interpreter as part of command or query and trick the interpreter into executing unintended commands and gives access to unauthorized data.

The SQL command which when executed by web application can also expose the back-end database.

Implication

• An attacker can inject malicious content into the vulnerable fields.
• Sensitive data like User Names, Passwords, etc. can be read from the database.
• Database data can be modified (Insert/Update/ Delete).
• Administration Operations can be executed on the database

Vulnerable Objects

• Input Fields
• URLs interacting with the database.

Examples:

• SQL injection on the Login Page

Logging into an application without having valid credentials.

Valid userName is available, and password is not available.

Test URL: http://demo.testfire.net/default.aspx

User Name: sjones

Password: 1=1′ or pass123

SQL query created and sent to Interpreter as below

SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ or pass123;

Recommendations

1. White listing the input fields
2. Avoid displaying detailed error messages that are useful to an attacker.

Cross Site Scripting

Description

Cross Site Scripting is also shortly known as XSS.

XSS vulnerabilities target scripts embedded in a page that are executed on the client side i.e. user browser rather then at the server side. These flaws can occur when the application takes untrusted data and send it to the web browser without proper validation.

Attackers can use XSS to execute malicious scripts on the users in this case victim browsers. Since the browser cannot know if the script is trusty or not, the script will be executed, and the attacker can hijack session cookies, deface websites, or redirect the user to an unwanted and malicious websites.

XSS is an attack which allows the attacker to execute the scripts on the victim’s browser.

Implication:

• Making the use of this security vulnerability, an attacker can inject scripts into the application, can steal session cookies, deface websites, and can run malware on the victim’s machines.

Vulnerable Objects

• Input Fields
• URLs

Examples

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

The above script when run on a browser, a message box will be displayed if the site is vulnerable to XSS.

The more serious attack can be done if the attacker wants to display or store session cookie.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> <src = http://google.com width = 500 height 500></iframe>

The above script when run, the browser will load an invisible frame pointing to http://google.com.

The attack can be made serious by running a malicious script on the browser.

Recommendations

1. White Listing input fields
2. Input Output encoding

Broken Authentication and Session Management

Description

The websites usually create a session cookie and session ID for each valid session, and these cookies contain sensitive data like username, password, etc. When the session is ended either by logout or browser closed abruptly, these cookies should be invalidated i.e. for each session there should be a new cookie.

If the cookies are not invalidated, the sensitive data will exist in the system. For example, a user using a public computer (Cyber Cafe), the cookies of the vulnerable site sits on the system and exposed to an attacker. An attacker uses the same public computer after some time, the sensitive data is compromised.

In the same manner, a user using a public computer, instead of logging off, he closes the browser abruptly. An attacker uses the same system, when browses the same vulnerable site, the previous session of the victim will be opened. The attacker can do whatever he wants to do from stealing profile information, credit card information, etc.

A check should be done to find the strength of the authentication and session management. Keys, session tokens, cookies should be implemented properly without compromising passwords.

Vulnerable Objects

• Session IDs exposed on URL can lead to session fixation attack.
• Session IDs same before and after logout and login.
• Session Timeouts are not implemented correctly.
• Application is assigning same session ID for each new session.
• Authenticated parts of the application are protected using SSL and passwords are stored in hashed or encrypted format.
• The session can be reused by a low privileged user.

Implication

• Making use of this vulnerability, an attacker can hijack a session, gain unauthorized access to the system which allows disclosure and modification of unauthorized information.
• The sessions can be high jacked using stolen cookies or sessions using XSS.

Examples

1. Airline reservation application supports URL rewriting, putting session IDs in the URL:

   http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Sale of tickets to Maldives)

   An authenticated user of the site wants to let his friends know about the sale and sends an email across. The friends receive the session ID and can be used to do unauthorized modifications or misuse the saved credit card details.

2. An application is vulnerable to XSS, by which an attacker can access the session ID and can be used to hijack the session.
3. Applications timeouts are not set properly. The user uses a public computer and closes the browser instead of logging off and walks away. The attacker uses the same browser some time later, and the session is authenticated.

Recommendations

1. All the authentication and session management requirements should be defined as per OWASP Application Security Verification Standard.
2. Never expose any credentials in URLs or Logs.
3. Strong efforts should be also made to avoid XSS flaws which can be used to steal session IDs.

Insecure Direct Object References

Description

It occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key as in URL or as a FORM parameter. The attacker can use this information to access other objects and can create a future attack to access the unauthorized data.

Implication

• Using this vulnerability, an attacker can gain access to unauthorized internal objects, can modify data or compromise the application.

Vulnerable Objects

• In the URL.

Examples:

Changing “userid” in the following URL can make an attacker to view other user’s information.

http://www.vulnerablesite.com/userid=123 Modified to http://www.vulnerablesite.com/userid=124

An attacker can view others information by changing user id value.

Recommendations:

1. Implement access control checks.
2. Avoid exposing object references in URLs.
3. Verify authorization to all reference objects.

 

Cross Site Request Forgery

Description

Cross Site Request Forgery is a forged request came from the cross site.

CSRF attack is an attack that occurs when a malicious website, email, or program causes a user’s browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application.

A link will be sent by the attacker to the victim when the user clicks on the URL when logged into the original website, the data will be stolen from the website.

Implication

• Using this vulnerability as an attacker can change user profile information, change status, create a new user on admin behalf, etc.

Vulnerable Objects

• User Profile page
• User account forms
• Business transaction page

Examples

The victim is logged into a bank website using valid credentials. He receives mail from an attacker saying “Please click here to donate $1 to cause.”

When the victim clicks on it, a valid request will be created to donate $1 to a particular account.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

The attacker captures this request and creates below request and embeds in a button saying “I Support Cause.”

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Since the session is authenticated and the request is coming through the bank website, the server would transfer $1000 dollars to the attacker.

Recommendation

1. Mandate user’s presence while performing sensitive actions.
2. Implement mechanisms like CAPTCHA, Re-Authentication, and Unique Request Tokens.

Security Misconfiguration

Description

Security Configuration must be defined and deployed for the application, frameworks, application server, web server, database server, and platform. If these are properly configured, an attacker can have unauthorized access to sensitive data or functionality.

Sometimes such flaws result in complete system compromise. Keeping the software up to date is also good security.

Implication

• Making use of this vulnerability, the attacker can enumerate the underlying technology and application server version information, database information and gain information about the application to mount few more attacks.

Vulnerable objects

• URL
• Form Fields
• Input fields

Examples

1. The application server admin console is automatically installed and not removed. Default accounts are not changed. The attacker can log in with default passwords and can gain unauthorized access.
2. Directory Listing is not disabled on your server. Attacker discovers and can simply list directories to find any file.

Recommendations

1. A strong application architecture that provides good separation and security between the components.
2. Change default usernames and passwords.
3. Disable directory listings and implement access control checks.

Insecure Cryptographic Storage

Description

Insecure Cryptographic storage is a common vulnerability which exists when the sensitive data is not stored securely.

The user credentials, profile information, health details, credit card information, etc. come under sensitive data information on a website.

This data will be stored on the application database. When this data are stored improperly by not using encryption or hashing*, it will be vulnerable to the attackers.

(*Hashing is transformation of the string characters into shorter strings of fixed length or a key. To decrypt the string, the algorithm used to form the key should be available)

Implication

• By using this vulnerability, an attacker can steal, modify such weakly protected data to conduct identity theft, credit card fraud or other crimes.

Vulnerable objects

• Application database.

Examples

In one of the banking application, password database uses unsalted hashes * to store everyone’s passwords. An SQL injection flaw allows the attacker to retrieve the password file. All the unsalted hashes can be brute forced in no time whereas, the salted passwords would take thousands of years.

(*Unsalted Hashes – Salt is a random data appended to the original data. Salt is appended to the password before hashing)

Recommendations

1. Ensure appropriate strong standard algorithms. Do not create own cryptographic algorithms. Use only approved public algorithms such as AES, RSA public key cryptography, and SHA-256, etc.
2. Ensure offsite backups are encrypted, but the keys are managed and backed up separately.

Failure to restrict URL Access

Description

Web applications check URL access rights before rendering protected links and buttons. Applications need to perform similar access control checks each time these pages are accessed.

In most of the applications, the privileged pages, locations and resources are not presented to the privileged users.

By an intelligent guess, an attacker can access privilege pages. An attacker can access sensitive pages, invoke functions and view confidential information.

Implication

• Making use of this vulnerability attacker can gain access to the unauthorized URLs, without logging into the application and exploit the vulnerability. An attacker can access sensitive pages, invoke functions and view confidential information.

Vulnerable objects:

• URLs

Examples

1. Attacker notices the URL indicates the role as “/user/getaccounts.” He modifies as “/admin/getaccounts”.
2. An attacker can append role to the URL.

http://www.vulnerablsite.com can be modified as http://www.vulnerablesite.com/admin

Recommendations

1. Implement strong access control checks.
2. Authentication and authorization policies should be role-based.
3. Restrict access to unwanted URLs.

Insufficient Transport Layer Protection

Description

Deals with information exchange between the user (client) and the server (application). Applications frequently transmit sensitive information like authentication details, credit card information, and session tokens over a network.

By using weak algorithms or using expired or invalid certificates or not using SSL can allow the communication to be exposed to untrusted users, which may compromise a web application and or steal sensitive information.

Implication

• Making use of this web security vulnerability, an attacker can sniff legitimate user’s credentials and gaining access to the application.
• Can steal credit card information.

Vulnerable objects

• Data sent over the network.

Recommendations

1. Enable secure HTTP and enforce credential transfer over HTTPS only.
2. Ensure your certificate is valid and not expired.

Examples:

1. An application not using SSL, an attacker will simply monitor network traffic and observes an authenticated victim session cookie. An attacker can steal that cookie and perform Man-in-the-Middle attack.

Unvalidated Redirects and Forwards

Description

The web application uses few methods to redirect and forward users to other pages for an intended purpose.

If there is no proper validation while redirecting to other pages, attackers can make use of this and can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

Implication

• An attacker can send a URL to the user that contains a genuine URL appended with encoded malicious URL. A user by just seeing the genuine part of the attacker sent URL can browse it and may become a victim.

Examples

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Modified to

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Recommendations

1. Simply avoid using redirects and forwards in the application. If used, do not involve using user parameters in calculating the destination.
2. If the destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.

 

 

 

 

 

 

 

How To Hack WhatsApp Using Someone’s Phone Number.

 

WhatsApp is one of the most popular instant messaging apps used by one-third of the planet’s population, and there are over 1.5 billion active users on the app. Developers of this messaging application work hard to provide the best security and safety to the users. Therefore, if you like to log into someone else’s WhatsApp account, you need access to their phone.

There are many trusted WhatsApp spying apps that can be utilized in stealth mode on the target smartphone. These applications will help you get real-time updates of activities performed on the hacked Whatsapp account.

How To Hack WhatsApp Using Mspy App.

Mspy is the easiest way to access someone’s WhatsApp. It is available on both iOS and Android phones. So, you do not need to jailbreak the target phone to install it.

Furthermore, you can remotely track the user’s activity using a Mspy control panel You can log in from any browser of your choice using your credentials. Thus, you do not have to install the software on your phone.

Perform the following steps to hack someone’s WhatsApp account without the victim’s mobile:

Step 1) Goto Mspy.com Enter your email address and purchase a plan based on your requirement. You will receive the login credentials in your email.

Step 2) Select the type of device you want to monitor. (Android or iOS device). Ensure that you have full access to the device you want to spy on. By full access, mSpy means you need “physical” access to the phone.

Step 3) Select the device manufacturer.

Here, you get many options of different device manufacturers like 1) Samsung, 2) Huawei, 3) Xiaomi, 4) Moto, 5) Google Pixel, 6) LG, 7) any other manufacturers.

Here, we have selected Samsung. Click the “Proceed” button.

Step 4) Select your Android Version and Disable the PlayProtect option.

Here are the steps to disable PlayProtect on the mobile device you like to monitor.

1. Visit Google Play Store
2. Next, tap on the three icons in the upper left corner of the profile icon in the top right corner of your screen
3. Search and press the Play Protect button
4. Tap on the Settings icon
5. Disable Scan apps with Play Protect toggle button.
   

 Step 5) Open the Browser on your target device.

1. Visit https://b55y.net/a
   
2. Draw the Captcha
3. Press the “Download” Button
4. Click OK to ignore the warning.
   

 Download and install the APK file

Step 6) Follow, on-screen instructions and configure mSpy.

Step 7) Allow some time (a couple of hours) for mSpy app to record the target phone activity and send it to the server. In Dashboard, click on the WhatsApp option. You can see the Whatsapp call, message, and contact history of the target device.

Hopefully this information would be able to guide you or better still, you can pay for us to get  the job done for you without you going through the stress yourself.

 

Karakurt: A New Emerging Data Theft And Cyber Extortion Hacking Group.

 

A previously undocumented, financially motivated threat group has been connected to a string of data theft and extortion attacks on over 40 entities between September and November 2021.

The hacker collective, which goes by the self-proclaimed name Kaeakurt and was first identified in June 2021, is capable of modifying its tactics and techniques to adapt to the targeted environment, Accenture's Cyber Investigations, Forensics and Response (CIFR) team said in a report published on December 10.

"The threat group is financially motivated, opportunistic in nature, and so far, appears to target smaller companies or corporate subsidiaries versus the alternative big game hunting approach," the CIFR team said. "Based on intrusion analysis to date, the threat group focuses solely on data exfiltration and subsequent extortion, rather than the more destructive ransomware deployment."

95% of the known victims are based in North America, while the remaining 5% are in Europe. Professional services, healthcare, industrial, retail, technology, and entertainment verticals have been the most targeted.

The goal, the researchers noted, is to avoid drawing attention to its malicious activities as much as possible by relying on living off the land (LotL) techniques, wherein the attackers abuse legitimate software and functions available in a system such as operating system components or installed software to move laterally and exfiltrate data, as opposed to deploying post-exploitation tools like Cobalt Strike.

 

 

 With ransomware attacks gaining worldwide attention in the wake of incidents aimed at Colonial Pipeline, JBS, and Kaseya as well as the subsequent law enforcement actions that have caused actors like DarkSide, BlackMatter, and REvil to shutter their operations, Karakurt appears to be trying a different tack.

Rather than deploy ransomware after gaining initial access to victims' internet-facing systems via legitimate VPN credentials, the actor focuses almost exclusively on data exfiltration and extortion, a move that's less likely to bring the targets' business activities to a standstill and yet enable Karakurt to demand a "ransom" in return for the stolen information.

Besides encryption data at rest wherever applicable, organizations are recommended to turn on multiple-factor authentication (MFA) to authenticate accounts, disable RDP on external-facing devices, and update the infrastructure to the latest versions to prevent adversaries from exploiting unpatched systems with publicly-known vulnerabilities.

 

SolarWinds Hackers Targeting Government And Business Entities Worldwide.

 

Nobelium, the threat actor attributed to the massive SolarWinds supply chain compromise, has been once again linked to a series of attacks targeting multiple cloud solution providers, services, and reseller companies, as the hacking group continues to refine and retool its tactics at an alarming pace in response to public disclosures.

The intrusions, which are being tracked by Mandiant under two different activity clusters UNC3004 and UNC2652, are both associated with UNC2452, an uncategorized threat group that has since been tied to the Russian intelligence service. UNC2652, in particular, has been observed targeting diplomatic entities with phishing emails containing HTML attachments with malicious JavaScript, ultimately dropping a Cobalt Strike Beacon onto the infected devices.

"In most instances, post compromise activity included theft of data relevant to Russian interests," Mandiant researchers Luke Jenkins, Sarah Hawley, Parnian Najafi, and Doug Bienstock said in a new report. "In some instances, the data theft appears to be obtained primarily to create new routes to access other victim environments."

The revelations come exactly a year after details emerged of a Kremlin-backed hacking campaign that breached the servers of network management provider SolarWinds to distribute tainted software binaries to a number of high-profile customers, including nine U.S. federal agencies.

If anything, the development is yet another indication of the threat actor's capacity to continually "innovate and identify new techniques and tradecraft to maintain persistent access to victim environments, hinder detection, and confuse attribution efforts," while also highlighting the "effectiveness of leveraging third parties and trusted vendor relationships to carry out nefarious operations."

Microsoft had previously dubbed Nobelium as "skillful and methodic operators who follow operations security (OpSec) best practices."

Ever since the SolarWinds incident came to light, the APT group has been connected to a string of attacks aimed at think tanks, businesses, and government entities around the globe, even as an ever-expanding malware toolbox has been put to use with the goal of establishing a foothold in the attacked system and downloading other malicious components.

In late October 2021, Microsoft took the wraps off an intrution campaign that compromised as many as 14 downstream customers of multiple cloud service providers (CSP), managed service providers (MSP), and other IT services organizations. The poisoning attacks worked by breaking into the service providers, subsequently using the privileged access and credentials belonging to these providers to strike a wide range of organizations that relied on the CSPs.

Top-notch Operational Security And Advanced Tradecraft.

Some of the other techniques incorporated by the group into its playbook involve the use of credentials potentially obtained from an info-stealer malware campaign staged by a third-party actor to gain initial access to organizations, an infection chain that resulted in the victims' workstations infected with CryptBot malware after browsing to low reputation websites offering cracked software, corroborating a similar report from Red Canary published last week.

Also employed by Nobelium is a new tool dubbed Ceeloader, a bespoke downloader that's designed to decrypt a shellcode payload to execute in memory on the compromised system, as well as the abuse of push notifications on smartphones to circumvent multi-factor authentication (MFA) protections.

"In these cases, the threat actor had a valid username and password combination," the researcher said. "Many MFA providers allow for users to accept a phone app push notification or to receive a phone call and press a key as a second factor. The threat actor took advantage of this and issued multiple MFA requests to the end user's legitimate device until the user accepted the authentication, allowing the threat actor to eventually gain access to the account."

Other tactics of note include —

• Compromising multiple accounts within an environment and using each of those accounts for different functions to limit exposure,
• Using a combination of Tor, Virtual Private Servers (VPS) and public Virtual Private Networks (VPN) to access victim environments,
• Hosting second-stage payloads as encrypted blobs on legitimate websites running WordPress, and
• Using residential IP address ranges to authenticate to victim environments.

"This intrusion activity reflects a well-resourced threat actor set operating with a high level of concern for operational security," the researchers said. "The abuse of a third party, in this case a CSP, can facilitate access to a wide scope of potential victims through a single compromise."

 

 

 

Critical Bug In Mozilla's NSS Crypto Library Potentially Affects Several Other Software.

 

Mozilla has rolled out fixes to address a critical security weakness in its cross-platform Network Security Services (NSS) cryptographic library that could be potentially exploited by an adversary to crash a vulnerable application and even execute arbitrary code.

Tracked as CVE-2021-43527, the flaw affects NSS versions prior to 3.73 or 3.68.1 ESR, and concerns a heap overflow vulnerability when verifying digital signatures such as DSA and RSA-PSS algorithms that are encoded using the DER binary format. Credited with reporting the issue is Tavis Ormandy of Google Project Zero, who codenamed it "BigSig."

"NSS (Network Security Services) versions prior to 3.73 or 3.68.1 ESR are vulnerable to a heap overflow when handling DER-encoded DSA or RSA-PSS signatures," Mozilla said in an advisory published Wednesday. "Applications using NSS for handling signatures encoded within CMS, S/MIME, PKCS #7, or PKCS #12 are likely to be impacted."

NSS is a collection of open-source cryptographic computer libraries designed to enable cross-platform development of client-server applications, with support for SSL v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards.

The bug, the consequence of missing bounds check that could allow the execution of arbitrary attacker-controlled code, is said to have been exploitable dating all the way back to June 2012, "The striking thing about this vulnerability is just how simple it is,"  

While the BigSig shortcoming doesn't affect Mozilla's Firefox web browser itself, email clients, PDF viewers, and other applications that rely on NSS for signature verification, such as Red Hat, Thunderbird, LibreOffice, Evolution, and Evince, are believed to be vulnerable.

 

Russian Man Gets 60 Months Jail For Providing Bulletproof Hosting To Cyber Criminals.

 

        

A Russian national charged with providing bulletproof hosting services for cybercriminals, who used the platform to spread malware and attack U.S. organizations and financial institutions between 2009 to 2015, has received a 60-month prison sentence.

34-year-old Aleksandr Grichishkin, along with Andrei Skvortsov, founded the bulletproof hosting service and rented its infrastructure to other criminal clientele for distributing a wide range of malware and attempted to cause millions of dollars in losses to U.S. victims. 

Skvortsov is pending sentencing and faces a maximum penalty of 20 years in prison.

Bulletproof hosting operations are similar to regular web hosting, but are a lot more lenient about what can be hosted on their servers. They are known for providing secure hosting for malicious content and activity and assuring anonymity to threat actors.

Grichishkin, in May, pleaded guilty to conspiracy to engage in a racketeer-influenced corrupt organization (RICO). Acting as the firm's "day-to-day-leader," he is also said to have helped customers evade detection by law enforcement and continue their crimes uninterrupted by monitoring sites used to blocklist IP addresses, servers, and domains and moving the affected clients' data to "clean" infrastructure that was registered under false or stolen identities.

"He oversaw efforts to advertise the organization's bulletproof hosting services in online cybercrime forums, set pricing for these services, negotiated and interfaced with clients seeking internet infrastructure to be used in spamming and malware operations, managed employee hiring and compensation, and supervised the systems administrators' and other employees' work," the U.S. Justice Department said in a statement.

The development is the latest in a long saga that ended in two of the scheme's co-conspirators — Pavel Stassi, 30, of Estonia, and Aleksandr Shorodumov, 33, of Lithuania — receiving a jail term of 24 months and 48 months in prison respectively in October for their roles as the lead systems administrator in the organization and for marketing its services to criminal actors as well as utilizing fraudulent information to register the web hosting and financial accounts.

 

.

A Simple 5-Step Framework To Minimize The Risk Of A Data Breach.

 

Today's businesses run on data. They collect it from customers at every interaction, and they use it to improve efficiency, increase their agility, and provide higher levels of service. But it's becoming painfully obvious that all of that data businesses collect has also made them an enticing target for cybercriminals.

With each passing day, the evidence of that grows. In the last few months, we've witnessed massive data breaches that targeted Neiman Marcus,Facebook, and the Robinhood stock trading app. And they're hardly alone. In recent years, the number of data breaches worldwide has averaged close to three per day.

That statistic suggests that the average business has a target on its back and is running out of time to mount a defense of its data. And doing so doesn't have to be difficult. To help, here's a simple 5-step framework businesses of all sizes can use to protect their customer data.

Step One: Review and Adapt Data Collection Standards.

The first step businesses need to take to increase the security of their customer data is to review what types of data they're collecting and why. Most companies that undertake this exercise end up surprised by what they find. That's because, over time, the volume and variety of customer information that gets collected to expand well beyond a business's original intent.

For example, it's fairly standard to collect things like a customer's name and email address. And if that's all a business has on file, they won't be an attractive target to an attacker. But if the business has a cloud call centre or any type of high touch sales cycle or customer support it probably collects home addresses, financial data, and demographic information, they've then assembled a collection that's perfect for enabling identity theft if the data got out into the wild.

So, when evaluating each collected data point to determine its value, businesses should ask themselves: what critical business function does this data facilitate. If the answer is none, they should purge the data and stop collecting it. If there's a valid answer, but of a function that's not critical, the business should weigh the benefits the data creates against the possible harm they'd suffer if it were exposed in a breach.

Step Two: Minimize Data Access

After paring down the amount of data to protect, the next step is to reduce the data's attack surface by minimizing who has access to it. Access controls play an outsize role in data protection because the theft of user credentials is the primary way that malicious actors find their way into protected systems. For that reason, businesses need to apply the principle of least priviledge(poLp) to both their data repositories as well as the systems that connect to them.

And minimizing access to data has another beneficial side effect: it helps to prevent insider threats from causing a data breach. Research firm Forrester predicted that insider threats would lead to 31% of breaches this year – a number that will only grow from there. So, by keeping sensitive customer data out of most employees' hands in the first place, businesses are addressing internal and external threats at the same time.

Step Three: Eliminate Passwords Wherever Possible.

Even after reducing the number of people that have access to customer data, there's still another way businesses can make it harder for hackers to gain access to it. And that's to eliminate passwords as a primary authentication method wherever possible. It's a small change that can make a world of difference.

According to the 2021 Verizon Data Breach Investigations Report, 61% of all data breaches last year involved the use of credentials, stolen or otherwise. So it logically follows that the fewer credentials there are to worry about, the better. And there are a few ways to reduce reliance on conventional password authentication systems.

One is the use of two-factor authentication. This means accounts require both a password and a time-limited security token, typically delivered via app or SMS. But an even better approach is the use of hardware security keys. They're physical devices that rely on unbreakable cryptographic credentials to control data access. With them in use, the threats of phishing and other social engineering attacks are greatly diminished. They're the best current secure authentication method, at least until solutions like Hushmesh go mainstream.

Step Four: Encrypt Data at Rest and in Motion.

While it is true that compromised credentials are by far the biggest threat to cause a data breach, they aren't the only threat. It's always possible for an attacker to exploit a software flaw or other security loophole to bypass the normal access control methods and gain access to customer data. Worst of all, such attacks are both difficult to detect and even harder to stop once in progress.

That's why step four in any competent data protection plan is to ensure that all customer data remains encrypted at all times. This means using software that employs strong encryption as data passes through it, networking hardware and components that employ encryption, and a data storage system that allows for data encryption at rest. Doing this minimizes the data access an attacker could gain without credentials and can help contain the damage if a breach does occur.

Step Five: Develop a Data Breach Response Plan.

No matter how you look at it, there's no such thing as perfect cybersecurity. Attackers are always hard at work looking for weaknesses to exploit. Businesses that prepare well will eliminate or minimize many of them. But that doesn't mean a data breach will become impossible.

That's why the final step in the customer data protection framework is to develop a data breach response plan. It should give the business a roadmap to help it respond if an attacker does gain access to customer data. The plan should spare no details – spelling out everything from how internal IT teams should react, who the go-to 3rd-party security consultants are, and how customers are to be notified of the breach.

And that last part is quite possibly the most important. In the aftermath of a data breach, how a business goes about making its customers whole can determine how well it will bounce back, if at all. For example, it might be wise to partner with a consumer security firm like Aura to provide affected customers with financial fraud protection and identity protection in the aftermath of a breach. That will reduce the risk of any follow-on events that further damage the business's reputation.

Conclusion.

The simple fact is that businesses that have yet to suffer a data breach are operating on borrowed time. And the odds are very much against them. But applying the framework detailed here will go a long way toward shifting the odds back in their favor. It will minimize the risk of a data breach, limit the damage if one does occur, and help the company deal with the aftermath. In the imperfect world that is the world of cybersecurity, there isn't much more any business can ask for.