WordPress has many advantages and is not without reason the most popular way to build a website, with 60% of pages on the web based on it. Unfortunately, it is this popularity that makes WordPress a juicy target for malicious users. Every year hundreds of thousands of WordPress and ecommerce sites get hacked.
So, is WordPress secure?
Attackers don’t get in thanks to security flaws in WordPress’s latest core software. Rather, most hacks can be easily prevented by taking simple steps like keeping things updated and securing passwords.
Top 5 ways WordPress sites get hacked
According to data, here are the top 5 ways WordPress websites get hacked:
1. Out-Of-Date Core Software 2. Out-Of-Date Themes and Plugins 3. Compromised Login Credentials for WordPress, FTP or Hosting 4. Supply Chain Attacks 5. Poor Hosting Environment and Out-Of-Date Technology
1.Out-of-date Core Software
According to WPScan Vulnerability Database, ~76% of the known vulnerabilities they logged are in the WordPress core software. But if we look at the version of WordPress those vulnerabilities were found, then we can see that 9 out of 10 most vulnerable WordPress versions are WordPress 3.x.x. Unfortunately only 21.5% of websites run on the latest version of WordPress.
2.Out-Of-Date Themes and Plugins
While themes and plugins are great for extending your site, each extension is a new potential gateway for a malicious actor. While most WordPress developers do a good job at following code standards and patching any updates as they become known, there are still a few issues:
– A plugin or theme has a vulnerability – The developer has stopped working on the theme or plugin but people are still using it – The developer patches the issue, but people don’t update
3.Compromised Login Credentials for WordPress, FTP or Hosting
A non-trivial percentage of hacks are from malicious actors getting their hands on WordPress, hosting or FTP account credentials.
Once the attacker has the key to your front door, it doesn’t matter how otherwise secure your WordPress site is.
WordPress does a great job mitigating this by generating secure passwords. It’s still up to users to keep those passwords secure.
4.Supply Chain Attack
There are some instances where hackers used a nasty trick to gain access to sites. The malicious actor would:
– Purchase a previously high-quality plugin listed at WordPress.org – Add a backdoor into the plugin’s code – Wait for people to update the plugin and inject the backdoor
It’s hard to prevent such attacks as you are doing something you are supposed to do – you are keeping a plugin up-to-date. WordPress.org team usually quickly spots these issues and removes the plugin from the directory.
5.Poor hosting environment and Out-Of-Date Technology
A whopping ~28% of WordPress websites are still using PHP 5.6 or below. The support for PHP 5.6 expired at the end of 2018, and earlier PHP versions haven’t had security support for years. This opens you up to the potential of unpatched PHP security vulnerabilities. Using a secure hosting environment and recent versions of important technologies like PHP helps further ensure that your WordPress site stays safe. Always make sure your website is well maintained.
How to stay secure?
The only way to be completely sure your website is secure is to test it for vulnerabilities. Automated solutions like Bright are easy to deploy and you don’t have to be a security expert to start a scan. Bright is a SaaS solutions and new payloads are added faster than with any other traditional solution. Request a demo and check out how Bright can help you keeping your WordPress site secure.
The ever-present threat of Magecart attacks
Do you know what “skimming” is? It’s a method that hackers use to gather sensitive information in online payment forums. Credit card numbers, email addresses, and user passwords are stolen. Magecart is a form of data skimming. The targets of these attacks are online shopping cart systems, the most common one being Magento. Attackers get a hold of the customers’ payment card information and abuse it for their own gains. The main way of doing this is compromising a third-party piece of software, usually from a VAR. Magecart hackers implant their malicious code into a website. Then they steal credit card information when a user enters their credentials during the checkout phase of shopping.
But why are shopping carts such an alluring target for these hackers? Because shopping carts collect your payment information. Hackers can do a lot of harm if they manage to tap into this data stream. The problem lies with the eCommerce sites. Why? They don’t check open-source (third-party) code for vulnerabilities when they build their eCommerce site. This is a recipe for disaster as sometimes this code comes with vulnerabilities that can easily be exploited. Are these Magecart attacks dangerous just for individual users? Not exactly. Even gigantic businesses like Ticketmaster’s United Kingdom Website, Puma’s Australian website, and even British Airways got attacked as reported by CNCB. As you can see, Magecart attacks are a huge threat for anyone, be it a small business or a large enterprise.
How do Magecart attacks work
u003cbr/u003eFor a Magecart attack to succeed, it needs to perform three actions:
Access the website
To inject the skimming code a hacker first needs to gain access to the targeted website. One way is to breach the defenses of the infrastructure or the server and then inject the skimmer. Another way includes targeting your third-party vendors. A third-party tag can be infected to run a malicious script on a site when it’s called in your browser. A hacker that achieves this then can then start skimming the data.
Skimming sensitive information
Many ways of capturing data exist. However, code that’s used for skimming is a piece of JavaScript code that finds personal information and collects it. An example of this is when a JavaScript intercepts the input of specific areas of a web form (credit card/CVV field). Magecart attacks even evolved over time. Hackers now conceal their malicious code inside a harmless code to avoid detection.
Sending acquired information back to the hacker’s server
Once a hacker gets to this part, the damage is already done. When they access the website and collect the data they need, you’ve lost. Hackers can now send this information to any place on the internet.
As you can see, Magecart hackers are dangerous. They can easily alter the Magento source or redirect the entire shopping cart to a malicious website by using injections. Is it easy to detect these attacks? It is if you’re ready to compare your entire eCommerce code stack one line at a time to see if anything was altered. A particularly nasty way Magecart attacks have been done includes uploading the malicious code to any unused GitHub project. Hackers that manage to take ownership of this project can then publish a new version of the code. One which contains malware. This propels the malware across a countless number of websites, spreading the infection further. Some security tools won’t even scan GitHub code. This way hackers and their malicious websites remain unnoticed, hiding in plain sight.
Which vulnerabilities get targeted by Magecart attacks
This is the age of open-source development. Source code is publicly available and anyone can study it, change it, and improve it. A lot of websites today are built based on many open-source components (third-party code). You have 20 companies that make and operate the code you’re using for your website. The problem lies within the privileges granted to the 3rd party code. Third-party code usually has the same level of privilege as your own code. Why is this a problem? Because this third-party code is able to exfiltrate sensitive data that is entered by users. It can even redirect the user to another website. Customers aren’t aware of these technical issues. They don’t know what it means for a website that’s built with code that’s hosted by 50 different development groups/organizations. Any vulnerability that comes from an open-source component leaves your website vulnerable as well.
Some Magecart groups are evolving their techniques. An attack on the Shopper Approved website proved that these attacks are a serious threat. This particular attack abused the vendor’s customer scoring plug-in. The plug-in got used to rate all kinds of websites that displayed badges of honor. Shopper Approved quickly removed the malware once it was identified. But the malware managed to spread across many eCommerce sites nonetheless.
Others stick to attacking shopping carts. However, they use a new method to infect advertising banners. These hackers utilize ad servers. By doing this the ad server places the Magecart code into a specific webserver. Any user that views this ad in their browser gets infected. A code gets downloaded to their computer.
Lastly, you have hackers that plan extremely targeted and complex attacks. Instead of the quantity, they focus on quality. These hackers spend a lot of time studying the code and the infrastructure of one target. British Airways happened to be a victim of this particular attack. Hackers exploited the logic flow of internal applications. The infected script targeted their baggage claim information page. Magecart then stole all the data that wasn’t stored on any of the servers that were owned by British Airways. This is how an XSS attack compromised British Airways’ servers. Testing your applications for XSS vulnerabilities is a much easier task when you use solutions like Bright. You can read more about this specific type of attack on one of our blogs.
How to protect yourself and your business
Now we know how Magecart attacks work and what their primary targets are. How does one protect themselves and their business against them? Protecting against attacks like this can be difficult. Just auditing a website every now and then won’t help. Why? The problem comes from third-party tags which are not detected by auditing. An effective prevention technique is a zero-trust approach with JavaScript on a website. A policy that will block access to any sensitive information entered in both stored cookies and web forums by default is a good start. Then only a selected set of vetted script should be allowed to access sensitive data. This approach makes it so skimming code can’t get access to any sensitive information when it gets on a website.
Web browsers don’t offer this option in most cases. Yet, users can make sure they’re not a victim of Magecart attacks in a couple of ways:
Avoid smaller websites that may not have a high level of security as bigger, more known websites
Check your credit cards for charges (Hackers make small test charges to make sure the targeted credit card is still active)
Use secure payment systems like Apple Pay (They generate unique numbers for each transaction so that attackers can’t re-use an obtained number)
Why are SAST solutions not always the best option for AST?
There are many methodologies you can use to detect application vulnerabilities. One of the most common methodologies is Static Application (or Analysis) Security Testing. Before we dive into the shortcomings of SAST solutions, let’s first outline what Static Application Security Testing is.
What is Static Application Security Testing?
SAST is a set of technologies that analyze the application’s code, byte code, and binaries line by line. As the analyzed code is transparent and available to the tool, Static Application Security Testing is a white-box testing technique.
Limitation 1: Inability to scan runtime applications
While SAST solutions can detect many common vulnerabilities like XSS, buffer overflow, and SQL Injection, they are limited to vulnerabilities that occur in the code itself. Unfortunately, many vulnerabilities in a runtime application do not actually exist in the code, but only arise when the application is compiled. If you rely solely on SAST solutions, you may release potentially vulnerable applications.
As an exampleStatic Application Security Testing falls short when it comes to finding issues connected to:
Authentication (is the code vulnerable to brute force attacks, or is a password reset as effective as it can be, etc.)
Sensitive data storage and transmission (especially in cases when it can’t tell the difference between sensitive and non-sensitive data)
Privilege escalation and lack of authorization
Data privacy (making sure it masks certain sensitive information when it’s displayed)
These issues become even more acute when dealing with a microservices environment where much of the code actually sits between the different services.
Some organizations don’t have access to the application’s source code. This is a big issue as Static Application Security Testing is complex. For it to function properly it needs a semantic understanding of the code. This includes the codes’ dependencies, configuration files, etc. and many of other pieces that are always in motion. Most dependencies aren’t even written in the same programming language. Can SAST understand all these moving pieces? While also being swift, accurate, and have a low false-positives rate? Not exactly.
Limitation 3: The need for a different SAST instance for every coding language
When an organization uses multiple code languages, multiple instances of SAST solutions are needed.
That means all of them require separate maintenance and configuration. This adds significant overhead.
Limitation 4: Limited coding language support
In addition to requiring a different SAST instance for each coding language used in an organization, SAST is limited to specific coding languages. While SAST providers are constantly adding support for new languages, there are some languages that will never be supported and others where SAST falls short from providing complete coverage.
As examples, the effectiveness of SAST is reduced when JavaScript, Python, and other dynamically typed languages are used.
JavaScript is the standard programming language of the web, and web is the most used computing platform ever built. SAST’s inability to work well with JavaScript represents a significant limitation. There are over 1.6 billion websites in the world. JavaScript is used in 95% of them.
Limitation 5: Disadvantages in a Microservices environment
Another issue with Static Application Security Testing tools is the Microservices architecture. SAST solutions can’t work in a world of Microservices. That’s a huge problem as most developers today use microservices architecture. Microservices architecture is highly maintainable and organized around business capabilities.
Check out best ways to test Microservices security.
Limitation 6: False Positives
One of the biggest problems with SAST solutions is that they are prone to false positives. Developers can get results that point out a lot of findings. Only it turns out most weren’t actually exploitable, or relevant. These results take time to examine and see if a flaw can damage your application or not.
Stay tuned for our next post that outlines the comparison between SAST & DAST.
Software vulnerability risks in the DevOps era
Accelerated software development means less time spent on security
Time to market is everything. In today’s industry, many companies bring products to market at a break-neck pace. What does this mean for software developers? They constantly need to release new builds. This significantly limits the amount of time they spend on testing for security vulnerabilities. DevOps is the reason why, as the process between IT teams and software development became automated once this set of practices entered the scene. Naturally, this made the speed of software development skyrocket. But this new practice of software development also came with its own risks, aka “Vulnerable Software”.
Software security is more important than ever
In most cases, standard application security approaches act as a gate throughout most of the software development stages. For developers to continue their work, security tests have to be completed first. Typically, the type of speed that DevOps gives also means that this gated application security approach doesn’t fit well.
The question is, how do we implement application security into the DevOps process to enable DevSecOps?
For starters, full control and visibility should be given to developers and organizations. This way security measures can be fully integrated into their work and software exposure can be mitigated throughout the entire software development life cycle (SDLC).
No more waiting for security professionals to run DAST tools and test for vulnerabilities as was the case in traditional development processes. Instead, empower developers, or QA people to run vulnerability tests as part of their unit testing processes and at the speed of DevOps. As the development processes evolve so should our security processes.
Integrate security directly into your work with DevSecOps
Do you know the best way to make sure software exposure doesn’t mess up everything? You inject security directly into a developer’s work. That way the software engineer has the information he needs right away, he can immediately come up with a solution to a certain problem. That’s the way you match software exposure management with the speed of DevOps efficiently!
A highly efficient method of integrating security during development is using DevSecOps. By making business and security staff cooperate, everyone can contribute to the cause of continuously testing the system during its entire development process. That way any defects can be detected, located, and remediated before a non-cooperative user locates them and exploits them. The earlier a problem is found and fixed, the less its repair costs.
All business processes need a dedicated team that will find flaws, test the system at all times, and communicate with the business operator and gives them all the information they need for further development. DevSecOps is an incredible way of enhancing traditional security testing and secure software development practices, which is a topic we already covered on our blog before, so check it out if you’re interested!
Data Breaches Due to Exposed Databases
As we wrap up our posts for 2019 we thought we would recap the “joy” of some significant breaches that happened in the past through years. May 2020 see us all secure and have no vulnerabilities exposed.
A massive breach of sensitive personal information in Ecuador is a recent case where there was no hacking involved at all. The owner of the data; an Ecuadorian company named Novaestrat, left an unsecured Elasticsearch database exposed on a publicly accessible server in Miami. The leaked database contained data about 20 million individuals (Ecuador has a population of 16 million, but some records were attributed to deceased individuals).
This is not the first time that a breach happens due to an exposed database, and while Elasticsearch appears to be the most popular platform, there are others.
Here are a few similar breaches from 2019:
1. Honda Motor Company Elasticsearch, 134 million rows of data about their employees
2. BioStar 2 Elasticsearch, over 1 million records including face recognition and fingerprint data
3. Orvibo Elasticsearch, 2 billion device user records
4. Thedatarepo MongoDB, 188 million personal records
5. Pyramid Hotel Group Wazuh – Open source intrusion detection system – 85 GB of security logs including personal data
9. Rubrik Elasticsearch, tens of gigabytes of customer data
10. CitiFinancial Elasticsearch, 24 million mortgage records
What’s the cause of these data breaches?
By default, Elasticsearch connects to a local address, and therefore it doesn’t publicly expose the database. To connect to a public address, Elasticsearch needs a manual configuration.
Until May this year, there were advanced security features available only in the paid version of Elasticsearch. Unfortunately, companies that decided to use a free version and save some money were obligated to secure DB’s on their own, and they failed to do so. In addition, it is important to mention that exposures can still happen anytime if software updates are not applied correctly. As such, the main cause of these data breaches is not technology but a lack of proper security policies in the business.
Sadly, many believe that if the database is not exposed to the internet, nobody can find it. Others are unable to implement proper security configuration in databases, software, and firewalls. Without a doubt, data breaches are happening and will keep occurring without adequate application security testing performed with correct security testing tools.
How can Bright help?
When it comes to data breaches due to exposed DBs and firewalls the only way to protect the system, data, and yourself is via regular application security testing implemented into the software development lifecycle. This enables for the entire infrastructure to be automatically scanned for vulnerabilities. Manual scans can be performed, but this is not a reliable practice because it doesn’t guarantee complete protection and it consumes a lot of resources. Instead, you can use Bright for web application security testing. With no false positives, Bright is a scalable enterprise solution, that is integrated into your Ci/CD and integrated into your unit testing and QA practices. It provides full automation of your web application scanning, and helps detect unauthenticated and exposed DB’s as well as weak administration panels. The integration into the SDLC enhances DevSecOps and delivers an immediate return of investment to organizations that decide to use it.
Implementing application security throughout the SDLC
Developers and students have to be told to pay attention to security
Recent studies show that developers do not actively pay attention to the security of their code unless directed otherwise. Still, application security is fundamental from the early stages of app development.
All team members, including developers and QA people, involved in the product design stage, should at least be aware of the need for application security.
The University of Bonn researched two groups with 20 Computer Science students each. Researchers gave the students a task to develop a registration program for the university’s social network. One group was explicitly told to store user passwords securely while the other group was not.
The participants who were not told to store user passwords securely didn’t make any effort to implement secure code. In the other group, out of 20 participants, 12 applied some level of security.
What if the study was conducted with web application developers instead?
The team from the University of Bonn did the same research with freelance developers. They posted an advertisement on freelancer.com, pretending to be a start-up company. The researchers specifically asked for the assistance of developers with the registration function of a sample social network website. Forty-three applicants were split into two groups. One of the groups was again told to store user passwords securely, while the other group was not.
Out of 18 participants who failed to include a secure password storage mechanism, 68% belonged to the group that was not instructed to implement secure code.
The study conducted on freelance developers confirms the tendency of developers not to implement security measures for storing user passwords unless otherwise directed.
Specifically requesting developers to write secure code plays a critical role in the design of any application.
Developers have to follow development and news in web security. Otherwise, they will make risky mistakes, like using weak hashing algorithms.
As seen in the research by the University of Bonn, developers often use weak methods. They often use encoding or encryption instead of hashing or use inadequate hashing algorithms. Developers need to examine these terms to find out the meaning, capability, and limits of each.
If we want to have secure web applications by design, we have to educate students and developers about the best, the latest and most secure solutions. A lack of knowledge about handling and securing user data will cause confusion, and worse, open a back door for malicious users.
Shortcomings of SAST tools / Why is DAST the better choice for integrating application security into the SDLC
Despite having access to source code and being able to test code for vulnerabilities, SAST tools have significant limitations. SAST tools can detect many different vulnerabilities in the code, but everything they identify is in the code and may not exist in the compiled application, or may not be relevant in the combined application. As an example, they can detect the absence of access control, but they cannot verify if it is running appropriately in the compiled application based on the actual implementation.
Another problem with SAST tools is that they produce high numbers of false-positive results. It’s difficult to verify whether or not some identified issues are actual vulnerabilities. This results in developers and security experts spending hours on end trying to distinguish between true vulnerabilities and false ones instead of focusing on resolving true vulnerabilities. Moreover, If SAST tools don’t find any problems, it does not mean that your code is secure as they only look at the code and not at the compiled application, APIs, etc. Related to this is the fact that most applications today use 3rd party libraries and web-services. SAST tools do not have the ability to test vulnerabilities in web-services, thus leaving your application vulnerable.
The problem with false positives persists with the majority of DAST tools as well. We are proud to say that Bright is one of the few DAST tools, if not the only one that will not report any false-positive findings. We validate that every vulnerability can actually be exploited before we report it.
Shift security left with Bright
Shift left is a simple term for a challenging task which is at the heart of DevOps. You need to move application deployment, quality and security considerations closer to the developer to ensure that potential issues are detected and resolved sooner as early as possible and at the lowest cost. CI/CD automation technology including CircleCI, Azure DevOps and others certainly makes shift-left easier.
As our previous post about the cost of remediating issues over time shows, the cost associated with bugs and security issues as they move through the delivery chain multiplies several times over at each step.
By addressing issues at the point of origin, shifting left has a clear ROI. In traditional development, dedicated teams are responsible for security and quality assurance. They generally respond to issues, not necessarily preventing them. Once the code is moved to integration or production, it is often too late to take precautionary measures. Also, IT teams are focused on system-level security, which is different than application security, where sneaky issues can be missed without security testing tools.
Bright seamlessly integrates into your SDLC and enable developers and QA teams to run application security tests throughout the CI/CD process. By choosing Bright’s AIAST ® solutions, organizations are able to test for known and 0-day vulnerabilities and security scans can be run early in the SDLC.
Resurgence of DAST for SDLC Integration and Scan Automation
Dynamic application security testing – DAST is one of the oldest automated application security testing techniques, it has been around since the mid-1990s. DAST solutions interact with live web applications and web services, acting like a hacker-in-a-box. It has always been popular with penetration testers and security auditors looking to save valuable time.
DAST is generally focused on detecting high-risk vulnerabilities. It performs an “end-to-end” test of all the functionality across all layers of an application and provides a proof-of-exploit, making issues much easier to validate and remediate than other techniques, like SAST (code scanning).
DAST solutions have been around since before Google existed. They continually struggled to find their place in the Software Development Life Cycle (SDLC) processes of most organizations until only a few years ago.
What has changed? – DAST Today
So, what brought on this change? The answer is simple – DevOps.
Collaboration between the security team, developers and DevOps is essential for security teams to enable the DevOps process. Through this collaboration, the DevOps process is transformed into DevSecOps.
This removes all the barriers that stood in the way of fully integrating DAST into the SDLC…
The automation of DAST as a part of the DevOps CI/CD pipeline offers a more reliable starting point for applications to be designed and implemented with proper security requirements.
Here are some common use cases in which DAST automation is very beneficial:
DAST & QA Functional Testing
Automating the use of DAST by leveraging functional test tools such as Selenium provides significant benefits. The purpose of QA automation tools is to test the application’s functionality and provide quality code with proper UX. By integrating DAST tools as part of this process you not only ensure quality code, but you provide secure code as well without any additional work.
Incremental Scans
Modern development practices rely on the delivery of small incremental pieces of code that are deployed faster than ever.
Developers continuously run unit tests to ensure quality code is deployed. DAST can be seamlessly integrated into these functional tests enabling incremental security scans of new or updated functionality and reducing the time and effort security testing time. Moreover, enabling developers to detect security vulnerabilities during the development process enables them to resolve issues very quickly, whereas it takes much longer to resolve these issues if they are detected weeks, or months later.
Testing API’s & Web Services
RESTful API’s and web services comprise a large percent of the code used in web applications. Since this code doesn’t have UI/frontend, organizations usually neglect to test it making them more exposed to cyberattacks. Integrating DAST into functional tests enables them to interact with each web service and API calls to detect and validate vulnerabilities.
Scanning Any Environment
One of the major advantages of DAST over SAST is that it doesn’t care what language is used to write an application. Whether it is Java, .Net, Phyton, C, Cobol, or any other language, or if you use MySql, Microsoft SQL server it doesn’t matter. Our AI-powered DAST solution is able to scan any target including HTTP/HTTPS, web socket, rest API to test the APIs themselves. This even extends to protocols such as Bluetooth, and FIX for financial institutions.
Detecting Real-World Issues
Over the past few years, microservices have become the leading method of application development. Modern apps are made up of multiple systems and components built by multiple teams and often multiple companies.
Since DAST scans applications and services in their running environment it is able to detect real-world vulnerabilities when microservices are used without the need to scan each component individually.
Learn about the top challenges of microservices security:
Shifting Security Left
The value DevSecOps offers is to conduct security testing earlier in the software development lifecycle. It enables to shift of testing left by adding security planning, testing, and monitoring into each phase of the DevOps pipeline.
Developers are under constant pressure to release as quickly as possible. Organizations can shift security left by integrating DAST into their existing environments, rather than relying on security testing at a later phase when the developer has moved onto something else.
Automating DAST into the process is critical for enabling DevSecOps. Release and scan as early and often as possible and ensure security throughout the entire software development life cycle. This will save both time and money without affecting development velocity.
Cybersecurity In the Era of Industry 4.0
In the era referred to as ‘Industry 4.0’ or ‘The Fourth Industrial Revolution,’ two of the pillars of the technology field; automation and data transfer are closely coupled with concerns regarding cybersecurity.
As organizations own, or use more and more information and assets which become additional nodes in the network, the attack surface area increases exponentially. As a result, cybersecurity aspects are transforming at an unprecedented rate. The challenges to security are becoming more prominent than ever, with both sides– hackers and security teams – trying to stay ahead of each other. In today’s hyper-connected world, cyberattacks are no longer a matter of “if”, but rather “when”.
What is industry 4.0?
As the use of computers and automation led the charge through the last few decades, organizations and governments focused their efforts on investments in the IT infrastructure era, which is referred to as ‘Industry 3.0’.
However, today, the focus has shifted to new technologies such as IoT (Internet of Things), AI (Artificial Intelligence), machine learning and reinforcement learning which are defining the new work culture across almost all industries. Industry 4.0 essentially blends automation with advanced AI to reduce direct human effort and resources. The result is a more efficient utilization of both financial and material resources.
In the era of the Fourth Industrial Revolution, organizations are hyper-connected with smart devices and smart networks. This poses a very lucrative target for hackers who can try to exploit the significantly higher number of vulnerable entry points into networks and devices. . Cyberattacks on critical infrastructure and in vital industrial sectors have become more frequent and more sophisticated.
IoT – Internet of Things
Internet of Things describes a world in which smart technologies enable objects within an intelligent network to communicate with each other and interface with humans effortlessly.
This connected world of accessibility and technology does not come without its consequences, as interconnectivity implies hackability. Most of these devices are designed with little to no built in security mechanisms, making them easy targets for security breaches. This new world of convenience calls for new and revolutionary protection measures and strategies to assure secure networks.
Blockchain
As a concept, blockchain has been around for approximately a decade. It is a well understood and defined concept that forms the backbone of most common cryptocurrencies. Blockchain, as a technology, focusses on the integrity and immutability of transactions. While blockchain as a technology is evolving, it offers solutions that can compete with current centralized offerings in terms of speed, but the blockchain is much more reliable considering capacity and trust. Inevitably, in IoT, blockchains will be used to secure infrastructure while maintaining device interoperability.
Although blockchain holds immense promise and potential, it remains vulnerable to cyber threats and risks. A robust cybersecurity program is therefore crucial for protecting blockchain assets from cyber threats.
AI – Artificial Intelligence
Artificial Intelligence is another technology that is rapidly permeating organizations and government departments. It is a branch of computer science that helps to build solutions with human-like intelligence that can carry out complex tasks independently.
AI applications are based on heuristics such as neural networks, machine learning, deep learning and natural language processing algorithms. Machines mimic humans only after they are trained to accomplish specific activities by processing vast amounts of data and identifying patterns in that data. The growing interest in these technologies and the value they offer is resulting in their adoption across many aspects of software and IT..
AI has the potential to make cybersecurity more efficient and responsive to ever-increasing threats and improve the cybersecurity posture of an organization
The Way Forward
The more industries become connected, the more vulnerable they are to the risk of cyberattacks because there are significantly more entry points for hackers to find and exploit. Hackers can target the connected devices that generate data, the networks that carry the data, the servers that host it, or the information systems that use it.
AI has the potential to make cybersecurity more efficient and responsive against ever-increasing threats and improve the cybersecurity posture of organizations. Being the world’s first AI-powered Application Security Testing platform, Bright helps innovative companies that are in the forefront of the Industry 4.0 era significantly reduce cybersecurity risks.
Cybersecurity should never be an obstacle to progress. Bright’s AI powered application security solutions help organizations save time and eliminate the security personnel bottleneck while reducing costs and their exposure window by being secure by design.
To learn more about how you can adopt these tactics in your organization and embrace the fourth industrial revolution, or you have any questions on how to become secured by design contact us today.
The Cost of a Data Breach and Latest Statistics
The Average Cost of a Data Breach
For the 14th year, IBM and the Ponemon Institute have released their annual “Cost of a Data Breach” report, aggregating the costs reported by 507 organizations, from 17 industries, and 16 regions. IBM and Ponemon interviewed 3,211 individuals and collected data points regarding the number of client records stolen or lost in breaches, how the organization responded to the breach, and how their business did after the breach.
According to the report, data breaches cost $150 per record this year. Last year the average cost of a data breach was $148 per record.
The cost associated with a data breach can span anywhere from $1.25 million to $8.19 million depending on the country and the industry.
Healthcare is the most expensive industry when it comes to data breaches
The healthcare industry continues to be susceptible target for attackers when it comes to cyberattacks. Healthcare breaches are the most expensive and cost an organization $6.45 million per breach. For the ninth year in a row, healthcare organizations have had the highest costs associated with a data breach.
The average cost per breached healthcare record ($429) is more than double any other industry and substantially higher than the average $150.
Healthcare breaches can often take the longest to identify. It can pass up to 236 days before a breach is detected. Additionally, the healthcare industry, followed by the financial and pharmaceuticals industries, had the most significant difficulty retaining customers following a data breach.
The report breaks down every angle of a data breach, detailing how having mitigation in place can reduce the cost of a data breach. Having an incident response team or using encryption alone can reduce the cost, but by having both in place, a company could potentially decrease the cost of a breach by $720,000.
By having security automation deployed, companies experience around half the cost of a breach. Companies that have incident response teams, security testing tools, and security automation deployed could save $1.23 million per data breach on average.
The most expensive country to experience a data breach
The most expensive country to experience a data breach are the United States.
In the U.S., the average cost of a data breach increased from $7.91 million in 2018 to $8.19 million in 2019. That’s more than twice the global average.
The average number of records per breach is the highest in the Middle East and India.
Some of the biggest data breaches
Data breaches can affect businesses of all sizes, and in deed, some big companies and organizations suffered attacks in the past. Although large companies survive data leaks, they suffer great material and reputational losses. The problem becomes bigger with small and medium-sized companies where the result of a data leak can be devastating to them and mean the end of their business.
We gathered just some of the biggest data leaks in the past.
U.S Office of Personnel Management
COST: $500 million to several billion IMPACT: 4 million people, 21.5 million records
The United States Office of Personnel Management (OPM) reported that it had been the target of a data breach. Federal officials have described it as among the largest and most critical breaches of government data in the history of the United States. The data breach consisted of two separate, but linked attacks. The first attack was discovered on March 20, 2014, but the second attack was not found until April 15, 2015. FBI arrested a Chinese national suspected of helping the creation of the malware used in the breach.
Exactis
COST: $242.7 million IMPACT: 200+ million U.S. consumers and 110 million business contacts
Exactis, a marketing and data aggregation firm, was the subject of a data breach in which customer information ended up on the internet. The stolen data includes phone numbers, addresses, emails, and other information — like interests, habits, and the number of one’s children. Hackers frequently use this type of information to steal identities and break into accounts.
Yahoo!
COST: minimal $470 million IMPACT: 3 billion user accounts
Yahoo! suffered two significant data breaches. The records contained names, email addresses, telephone numbers, encrypted or unencrypted security questions and answers, dates of birth, and hashed passwords. Yahoo! has been criticized for its late disclosure of the breaches and their security measures. The breaches impacted Verizon Communications’s plans to acquire Yahoo! for about $4.8 billion. The FBI officially charged four mean for the 2014 breach, including two that work for Russia’s Federal Security Service (FSB).
Equifax
COST: $439 million to 4 billion IMPACT: 148 million Americans, 209,000 credit card numbers
Equifax announced in September 2017 that its systems had been breached and sensitive personal data had been compromised. The data included names, home addresses, phone numbers, dates of birth, social security numbers, and driver’s license numbers. The Equifax breach is unprecedented in scope and severity. There have been larger security breaches by other companies in the past, but the sensitivity of the personal information held by Equifax and the scale of the problem makes this breach unprecedented.
Epsilon
COST: $270 million to 4 billion IMPACT: 60 million users
Epsilon – the largest permission-based email marketing company, suffered a data breach. The breach was a result of an “unauthorized entry” to Epsilon’s email system. Companies like Walgreens, BestBuy, CitiGroup, JPMorgan, Capital One and others were all affected indirectly, as they were clients of Epsilon. No personally identifiable information was obtained, but the emails they got could be used for spam and phishing attacks.
TJX
COST: $256 million IMPACT: 94 million customers
Intruders gained access to TJX’s computer systems. The breach affected 94 millions of retail shoppers. Customers’ MasterCard and Visa cards had been compromised. Debit card PINs weren’t compromised, but hackers gained access to unencrypted magnetic stripe data. Several banks sued to recoup losses related to the breach.
Marriott
COST: $200 million to $1 billion IMPACT: 500 million customers, 383 million guest records, 18.5 million encrypted passport numbers
Marriott suffered a massive data breach. Information accessed included payment information, names, mailing addresses, phone numbers, email addresses and passport numbers. Details included 9.1 million encrypted payment card numbers and 385,000 valid card numbers in addition to 5.25 million unencrypted passport numbers.
Sony Playstation Network
COST: $171 million to $2 billion IMPACT: 77 million accounts
Sony suffered a data breach that exposed the names, addresses and other personal data of their users. An “Illegal and unauthorized person” got access to people’s names, addresses, email addresses, birthdays, usernames, passwords, logins, security questions and more for two days. Sony stated that it saw no evidence that credit card numbers were stolen, but advised users they credit card numbers and expiration date may have been obtained.
Uber
COST: $148 million IMPACT: 600,000 Drivers
Uber suffered a breach and concealed the hack for more than a year. The hackers were paid $100,000 by Uber to delete the data and keep the breach quiet. Driver’s license numbers of around 600,000 drivers in the U.S., names, email addresses, and mobile phone numbers were stolen. Uber agreed to pay $148 million in connection with this data breach and subsequent cover-up.
Veterans Administration
COST: $100 million to $500 million IMPACT: 26.5 million people
A Veterans Affairs data analyst took home a laptop and an external hard drive containing unencrypted information on 26.5 million people. The laptop and hard drive were stolen in a burglary of the analyst’s home. The employee admitted that he had been routinely taking home such sensitive data for three years. The stolen data included names, Social Security numbers, dates of birth, and some disability ratings.
