Dimensional Data

Published Apr 29, 2021 WRITTEN BY ED TITTEL. Ed Tittel is a long-time IT industry writer and consultant who specializes in matters of networking, security, and Web technologies. For a copy of his resume, a list of publications, his personal blog, and more, please visit www.edtittel.com or follow @EdTittel Although the term says “serverless,” serverless applications don’t really run without any servers involved. Rather, serverless applications run inside cloud-based infrastructures so that developers and operators need no longer stand up and run their own servers, virtual or physical. That is, the application still runs on a server, but the responsibility for server management falls on the cloud service or cloud platform provider instead. That means that organizations need not themselves provision, scale, manage and maintain servers on which their applications run – they use a serverless architecture to build, test, deploy and run their applications and services for clients, customers, end-users, and so forth. AWS Lambda, for example, is a serverless service that includes automatic scaling, with high availability baked into the runtime environment, charged on a pay-for-value basis. As is typical for cloud-based runtime environments, serverless applications adhere to what’s often called a “shared security model.” Following this model means that the cloud provider is responsible for the security of the cloud while those who host their applications are responsible for security of their application  in the cloud. When organizations adopt serverless technologies, the responsibility that the cloud or application provider assumes climbs up the stack to include operating system and networking security for the servers it operates on which the organization’s serverless application runs. Theoretically this means that the job of security is easier for serverless applications than for cloud-based applications where the operating organization also stands up underlying virtual infrastructures. In fact, Amazon recommends (and most other cloud service and platform providers concur) that companies adhere strictly to the Principle of Least Privilege (PLP) and also follow best practices for securing their serverless applications. They recommend their own identity and access management (IAM) platform to secure and manage access to their services and resources, but similar capabilities are available from all of the major cloud platform providers including Azure, Google, Oracle, IBM, Alibaba and others as well. Proper use of identity and access management technology is indeed key to securing serverless applications. This includes access controls through accounts and groups or job roles, and specific constraints on how users may interact with serverless applications. These might pertain to days of the week, times of the day, originating IP addresses, as well as require use of SSL or other secure protocols, and even require multi-factor authentication (2FA or better) before allowing access to proceed. In addition, most cloud platforms’ identity and access management tools support access auditing and reporting, so the organization’s security team and administrators can confirm that prevailing policies provide only authorized public and private accounts with appropriate access to applications and their resources. In fact, organizations should use this reporting to tweak and adjust their security policies to enable access only to services in use, following PLP. Multi-Factor Authentication (MFA) makes most sense for privileged accounts and access (administrators, developers, architects and security staff) so that privileged access is available only to those who provide a hardware MFA device, or who use an authentication app […]

Published April 22, 2021 WRITTEN BY THE KIUWAN TEAMExperienced developers, cyber-security experts, ALM consultants, DevOps gurus and some other dangerous species. Social media, advanced technology, and the growing popularity of business transactions over the web continue to determine how organizations operate and communicate with their prospective customers. However, they’re also gateways to cyberattacks and data loss. Whether launched by criminals, insiders, or run-on-the-mill hackers, the likelihood of a cyberattack exists, and both small and established organizations face the risk of moderate or severe harm. As a component of their risk management strategy, companies now have to routinely decide the risks to accept, control, avoid, or transfer. Risk transfer is where cyber insurance policies come into play. What Is Cyber Insurance?  It’s also called cyber liability insurance coverage (CLIC) or cyber risk insurance. In essence, the policy is designed to provide risk exposure mitigation to companies. It does this by offsetting any expenses the business incurs to recover after a security breach or any other cyber-related threat.  The concept entered the market in the early 2000s and has its roots in E&O (errors and omissions) insurance. Very few providers existed then, and the main threats covered included network security, viruses, and unauthorized access. A lot has changed from its initial inception. For instance, the earlier iterations mainly focused on third-party indemnity coverage. But as years went by, providers began including first-party coverage for credit monitoring, notification, crisis management, public relations, and identity restoration. Earlier on, the first-party coverages were sub-limited, contrary to the full limits available in the market right now. Soon after, additional like PCI penalties and fines, regulatory penalties and fines, first-party business interruption, and cyber extortion followed later. The recent years have seen the inclusion of social engineering, system failure coverage, and property damage to devices and hardware. Different advancements in the coverage’s scope are witnessed every year.   Types of Cyber Insurance Coverages Here are the different types of cybersecurity insurance coverages:  Cyber Security Insurance It’s also referred to as the Crisis Management Expense or Privacy Notification coverage. The insurance product covers you and your business against first-party damage but not against damage to third-parties. It specifically takes care of the immediate response cost after a data breach. Some of these costs include: Contracting forensic experts to ascertain the breach’s origin and give suggestions on practical approaches to site security and future breach prevention Paying a public relations service to help address the crisis Informing everyone whose personally identifiable information is compromised Monitoring the victims’ credit for 12 months Compensating the cost of restoring stolen identities Cyber Liability It’s also called the Information Security and Privacy Insurance and covers liability for breach damages. Direct response costs aren’t covered. It’s ideal for e-commerce agencies and those that keep client data in their internal electronic network. Common breaches involve the following types of personal or financial data: Credit card numbers Social security numbers Bank account details Health information Intellectual property or trade secrets Technology Errors and Omissions Also called E&O or Professional Liability, the liability coverage protects corporates that offer technology products and services. It protects you from bearing the entire cost of defending yourself when a civil lawsuit awards damages after a customer’s negligence claim. Apart from the companies selling and servicing computer products, the insurance also includes advertising […]

Published April 15, 2021 WRITTEN BY MICHAEL SOLOMON Michael G. Solomon, PhD, CISSP, PMP, CISM, PenTest+, is a security, privacy, blockchain, and data science author, consultant, educator and speaker who specializes in leading organizations toward achieving and maintaining compliant and secure IT environments. Many catastrophic events are obvious, with their effects immediately visible — but not all. Fire, flood, tornadoes and earthquakes are all examples of events that can cause a substantial impact to business operation and do not require any effort to detect. Everyone can see what causes the damage. Cyberattacks can be very different. While some cyberattacks, such as Denial of Service (DoS) attacks, cause interruptions that are immediate and visible, many other attacks are not so obvious. For example, an attack that extracts sensitive customer information likely will not raise alarms and can occur without anyone realizing what happened. Since the first step in responding to a security incident is to identify that an incident has occurred, identification becomes important to survival.  A recent IBM breach report states that companies that are victims of a cyberattack take an average of 207 days to identify the breach. And it takes, on average, an additional 73 days to contain it. Think about that: On average, victims of cyberattacks only realize they have been attacked after half the year has passed. Since many cybercriminals plunder their victims repeatedly after the initial breach, losses can accumulate the longer an attacker goes undetected. A key indicator of how much damage a cyberattack may cause is how soon that attack is detected and stopped. Early breach identification is the single most important action to reduce the blast radius and increase the likelihood of surviving the attack. Let’s look at some ways companies can place controls that provide an early alert of cyberattack activity. Like the canaries coal miners used to carry with them, an early warning of danger can help avert disaster. Manage cybersecurity risk Encountering business interruptions is not a new phenomenon. There are many ways an organization can run over operational “speed bumps” that reduce or completely block its ability to carry out its core business functions. These speed bumps are often referred to as risk. Risk is the probability that something will occur that has either a positive or negative effect. Most risk is perceived as something that may cause loss, but risk can have a positive result, such as finishing a project early. We will only cover negative risk in this article. A proven way to minimize the negative effects of realized risk is to develop plans to handle the risks that can cause the most damage. Of course, that is easier said than done. Ignoring risk is dangerous. But managing it well can be the difference between surviving and succumbing to a realized risk such as a cyberattack. The quality of your plans is directly related to your probability of success. Business Impact Analysis The first plan you will need to combat cyberattacks is a Business Impact Analysis (BIA). A BIA summarizes your business processes and identifies the functions that must be operational for your organization to stay in business. These core functions are called Critical Business Functions (CBFs). Once you have identified your CBFs, you know what you must protect. If any CBF gets interrupted, your business process […]

Published March 31, 2021 WRITTEN BY ED TITTEL. Ed Tittel is a long-time IT industry writer and consultant who specializes in matters of networking, security, and Web technologies. For a copy of his resume, a list of publications, his personal blog, and more, please visit www.edtittel.com or follow @EdTittel As applications become increasingly cloud-based – or even, cloud-native – more and more such code is sending data to and from cloud-based stores, both public and private. This makes the methods and controls that such applications use to access the cloud of particular interest. It also keeps the onus on application owners to protect and preserve application data, particularly when it involves information subject to compliance and regulatory requirements. That brings a host of other concerns into play that range from preserving privacy and confidentiality to the “right to be forgotten” (a GDPR requirement that obliges organizations to dispose of data about any registered individuals within 30 days of request for same, or face fines and penalties). Pass the Data, But Not the Buck Indeed, organizations must realize and own up to their responsibility for data, even when it leaves their hands and goes into the cloud. At best, the cloud service provider will assume a “shared responsibility” for an organization’s data once it hits their servers or data stores. But always, the organization that acquires (and presumably controls and protects) such data remains legally responsible for its privacy, confidentiality, and disclosures of breach, theft, or unwanted access or disclosure. Thus, organizations that use cloud platforms should thoroughly understand the provider’s security capabilities, and any data protection (such as encryption, access control and audit, and so forth) that the provider offers, and what responsibility and liability it assumes for data and applications that run within its systems. Best Security Practices for Cloud Access For cloud-consuming organizations, that’s just the beginning. Best security practices also insist that organizations implement the following principles where access to cloud applications, data, configurations, and resource consumption are concerned: Apply the Principle of Least Privilege (PLP): all access should be set to “deny” by default and only so much access allowed for authorized parties as they need to use an application (ordinary users) or administer the organization’s cloud environments and settings (and all admin level access should be logged, and routinely audited, especially use of privilege, account management, configuration and set-up of applications and data stores, and so forth). Use strong authentication, 2FA or better: Ideally, all access to cloud-based applications and data should require jumping demanding hurdles before access requests get granted. At a minimum, ordinary users should be required to use two-factor authentication (2FA: cellphone or email confirmation of one-time pads). Higher-level access, should probably use multi-factor authentication that includes something beyond 2FA, such as a certificate, smart token device, biometric data (fingerprint, facial scan, and so on), or be tied to a specific admin workstation’s MAC address. Encryption for data in motion and at rest: By default, organizations should turn on and use the strongest encryption they can employ without unduly affecting data access and/or application performance. Data should also be encrypted wherever it’s stored, both at endpoints when used on the client side, and in data stores when in use by an application or truly at idle rest (active or multi-tiered storage repositories). […]

Published April 08, 2021 WRITTEN BY MICHAEL SOLOMON Michael G. Solomon, PhD, CISSP, PMP, CISM, PenTest+, is a security, privacy, blockchain, and data science author, consultant, educator and speaker who specializes in leading organizations toward achieving and maintaining compliant and secure IT environments. Payment card attacks are nothing new. Cybercriminals have been targeting payment cards for more than a decade. However, there is a disturbing trend of cybercriminals discovering and leveraging novel ways to steal payment cards credentials during online transactions. Online merchants have long espoused techniques that make online commerce safe, but that assurance is under a new level of attack. Recent advances in payment card attack sophistication up the game for cybersecurity professionals. Protecting online commerce is always challenging, but it can be rewarding and effective. Let’s look at a few ways to stay at least one step ahead of emerging payment card threats. Understanding payment card threats Using someone else’s payment card to steal funds is an attack that has existed as long as payment cards. In the beginning, merchants would use a mechanical device to make an impression of the raised payment card numbers into a set of carbon-copied transaction records. The customer would sign the record and take one copy. A second copy would stay with the merchant, and a third copy would go to a payment processor to settle the payment. The early process was simple, and when the device that created payment card impressions would fail, vigorously rubbing a pen or pencil body over the card would transfer the image to the transaction record. In those days, if you could grab a payment card number and forge the owner’s signature, you could create fraudulent transactions. When online transactions started to become more prevalent, signatures became less important; all cybercriminals needed were elements of a payment card holder’s basic information, such as card number, name and billing address. Intercepting credit card numbers wasn’t very difficult, since encryption wasn’t the norm prior to the early 2000s. But it didn’t take long for the payment card industry to recognize the growing threat to transactions. Several of the biggest payment card industry vendors, including Visa, MasterCard, American Express, JCB International and Discover, joined forces to develop the Payment Card Industry Data Security Standard (PCI DSS). One of the many requirements of the PCI DSS is that all transmissions involving payment card data (and subsequent storage) must be encrypted. PCI DSS increased security and upped the ante for payment card attacks, so the cybercriminals upped their game as well. Now we see a wide range of attacks that focus on intercepting, or skimming, payment card numbers and related data prior to any encryption efforts. The general idea for today’s attacks is to find creative ways to push the attack closer to the point of payment card number acquisition. In the physical world, this led to portable and stealthy physical card skimmers. Card skimmers work by replacing a valid card reader with a device that reads the credit card data and then sends it to an attacker’s preferred repository. Sophisticated skimmers pass the data through to the intended destination to remain undetected for as long as possible. As small battery-powered skimmers became popular, unscrupulous servers at some restaurants began skimming cards with pocket skimmers before processing payment cards properly. (Of […]

Published March 31, 2021 WRITTEN BY ED TITTEL. Ed Tittel is a long-time IT industry writer and consultant who specializes in matters of networking, security, and Web technologies. For a copy of his resume, a list of publications, his personal blog, and more, please visit www.edtittel.com or follow @EdTittel As applications become increasingly cloud-based – or even, cloud-native – more and more such code is sending data to and from cloud-based stores, both public and private. This makes the methods and controls that such applications use to access the cloud of particular interest. It also keeps the onus on application owners to protect and preserve application data, particularly when it involves information subject to compliance and regulatory requirements. That brings a host of other concerns into play that range from preserving privacy and confidentiality to the “right to be forgotten” (a GDPR requirement that obliges organizations to dispose of data about any registered individuals within 30 days of request for same, or face fines and penalties). Pass the Data, But Not the Buck Indeed, organizations must realize and own up to their responsibility for data, even when it leaves their hands and goes into the cloud. At best, the cloud service provider will assume a “shared responsibility” for an organization’s data once it hits their servers or data stores. But always, the organization that acquires (and presumably controls and protects) such data remains legally responsible for its privacy, confidentiality, and disclosures of breach, theft, or unwanted access or disclosure. Thus, organizations that use cloud platforms should thoroughly understand the provider’s security capabilities, and any data protection (such as encryption, access control and audit, and so forth) that the provider offers, and what responsibility and liability it assumes for data and applications that run within its systems. Best Security Practices for Cloud Access For cloud-consuming organizations, that’s just the beginning. Best security practices also insist that organizations implement the following principles where access to cloud applications, data, configurations, and resource consumption are concerned: Apply the Principle of Least Privilege (PLP): all access should be set to “deny” by default and only so much access allowed for authorized parties as they need to use an application (ordinary users) or administer the organization’s cloud environments and settings (and all admin level access should be logged, and routinely audited, especially use of privilege, account management, configuration and set-up of applications and data stores, and so forth). Use strong authentication, 2FA or better: Ideally, all access to cloud-based applications and data should require jumping demanding hurdles before access requests get granted. At a minimum, ordinary users should be required to use two-factor authentication (2FA: cellphone or email confirmation of one-time pads). Higher-level access, should probably use multi-factor authentication that includes something beyond 2FA, such as a certificate, smart token device, biometric data (fingerprint, facial scan, and so on), or be tied to a specific admin workstation’s MAC address. Encryption for data in motion and at rest: By default, organizations should turn on and use the strongest encryption they can employ without unduly affecting data access and/or application performance. Data should also be encrypted wherever it’s stored, both at endpoints when used on the client side, and in data stores when in use by an application or truly at idle rest (active or multi-tiered storage repositories). […]

Published March 25, 2021 WRITTEN BY MICHAEL SOLOMON Michael G. Solomon, PhD, CISSP, PMP, CISM, PenTest+, is a security, privacy, blockchain, and data science author, consultant, educator and speaker who specializes in leading organizations toward achieving and maintaining compliant and secure IT environments. The successful attack in 2020 on the SolarWinds Orion network management software showed that indirect, or third-party, attacks on organizations of all sizes are feasible. Where direct attacks used to be the most common attack vector, especially when attempting to target large organizations, attacking smaller suppliers is becoming a more attractive approach. Any attack that attempts to compromise an organization by directly attacking one of its suppliers of hardware or software is called a supply chain attack. The SolarWinds attack was not the first attack on the IT supply chain, and it looks like the number of similar attacks is increasing. As more organizations become more secure, attackers are looking for creative ways to sneak their attacks in under the radar. Let’s look at the risk of IT supply chain attacks and what you can do to mitigate them. Understanding supply chain attacks Supply chain attacks were up 430% in 2020 over the previous year. The dramatic increase in supply chain attacks means that organizations must mobilize immediately to counter this emerging threat. Cybersecurity specialists are getting better all the time. Cybersecurity education and training is becoming more commonplace and in-depth, along with the development of increasingly sophisticated tools and techniques. Unfortunately, cybercriminals are getting better as well. Over the last decade, the increased level of security awareness and control sophistication has driven cybercriminals to search for softer targets. Security defense maturity is often consistent with size. Larger organizations generally have larger security budgets and can end up maintaining more secure IT environments. Saying that larger means more secure isn’t always accurate; there are lots of insecure large organizations and many very secure smaller ones. On average, though, cybercriminals know that smaller organizations are more likely to lack sophisticated security controls. Simply put, smaller organizations often do not have the budget for the best security. Consequently, many cybercriminals are recognizing a unique opportunity to indirectly attack large organizations by focusing their efforts on the smaller — hopefully softer — suppliers that those large organizations use. The basic approach in a supply chain attack is for the cybercriminals to add malicious code to software products during the development or release process. The malicious code becomes part of a software product that then gets sold to — and installed in — numerous unsuspecting customers’ environments. While the direct target of the attack is the supplier’s code, the eventual target is the customer’s environment into which the tainted code gets installed. The main reason an attack like this works is due to its novelty and the presence of general trust between supplies and customers. Few customers of SolarWinds products probably worried about the quality of the SolarWinds product line before the news of the Orion attack. The general perception is that a trusted supplier takes the necessary precautions to ensure their software is clean. Very few existing security tools or procedures validate the security of purchased products. That’s the problem, and the opportunity for cybercriminals. It has long been known that tampering with a product during delivery is possible, and controls […]

Published March 17, 2021 WRITTEN BY MICHAEL SOLOMON Michael G. Solomon, PhD, CISSP, PMP, CISM, PenTest+, is a security, privacy, blockchain, and data science author, consultant, educator and speaker who specializes in leading organizations toward achieving and maintaining compliant and secure IT environments. Software security isn’t a state of being, or even a single action; it is a process, and one that requires more than just hardening your software. The year 2020 saw a dramatic rise in cyberattacks, with many attacks specifically targeting IT infrastructure. Any attack that compromises an IT environment interrupts normal operations, which can effectively interrupt critical software operations. Regardless of how secure your software is, if you can’t access critical data or services, your application won’t be available to authorized users. And since availability is one of the “big three” tenets of security, unavailable effectively means insecure. Ensuring software security is an organic and community-driven effort. For the most effective result, focus on actions that provide benefits for your software and its surrounding environment.  The last thing you want to do is constantly put out fires. A better approach is to get ahead of the fires. Learn to anticipate attacks and take proactive measures. Here are some ways to create a balanced threat-handling environment to make your software more secure. Responding to attacks The first step to handling any attack is to recognize that there is an attack being carried out. That may sound simple, but in many cases it isn’t. Non-disruptive attacks like data exfiltration may go unnoticed for months. Security is challenging even under normal circumstances, and the problem of handling attacks is even worse given the pressures of today’s realities.  Organizations of all types were put under more pressure when the new realities of covid-19 changed the way people work and interact. But few sectors were impacted more than healthcare. In addition to changes in the workforce and patient interaction protocols, covid-19 stretched every aspect of delivering quality healthcare. IT service and security concerns were just one part of the bigger problem. And in the midst of all the additional pressure, ransomware attackers sensed an opportunity and launched an unprecedented number of attacks against the healthcare sector. For example, in October 2020, the University of Vermont (UVM) Medical Center suffered a successful ransomware attack that ended up disabling all online systems for several weeks. At first it wasn’t evident that the interruption was an attack, but once the nature of the attack did become clear, UVM personnel searched for nearly two hours before they found a file that contained a note from the attackers. CNN picked up on the alarming statistics and published a story about the UVM Medical Center attack, and the Cybersecurity and Infrastructure Security Agency (CISA) published an advisory warning of the increasing number of ransomware attacks on healthcare organizations. UVM had taken some precautions to harden their systems, but the attackers were still able to succeed. While there is no guaranteed approach that leads to an impenetrable defense, there are ways to make your organization far less vulnerable. There is a constant need to iterate over updated threat information to stay ahead of the attackers. The goal is to approach the problems of security in parallel. If all you do is respond when you receive a new attack alert, you’re […]

Published February 24, 2021 WRITTEN BY ED TITTEL. Ed Tittel is a long-time IT industry writer and consultant who specializes in matters of networking, security, and Web technologies. For a copy of his resume, a list of publications, his personal blog, and more, please visit www.edtittel.com or follow @EdTittel Few, if any, other repositories for data and meta-data within an organization exceed the importance and value of its databases (DBs). In fact, databases often provide a home for an organization’s personnel information, financial data of all kinds (pay, taxes, purchases, income, and other monetary transactions), and data describing its physical inventory and assets. Thus, it’s not unfair to observe that most of the data that defines “who, what, where, when, and why” for an organization is likely to reside in a database. All of this goes to explain why DB security is vitally important to an organization’s health and its ability to conduct business. Principles that drive DB security are well-understood In the realm of database security, informed professionals understand that while basic security principles definitely apply, they can (and often do) take a database-specific slant. Thus, any enumeration of such principles will often play to the special circumstances involved in defining database metadata (often called a “database schema” to emphasize its scope and coverage for some specific and related collection of data) and in setting up and managing a database engine of some kind (which may be on-premises, in one or more clouds, and various permutations on those themes). That said, here are how some of these basic principles play into the world of database security. 1. Principle of least privilege (aka PLP) In general, PLP means providing the minimum of access rights and user privileges necessary to perform some specific task, run an application, or work with database contents, software or infrastructure elements. As with other PLP situations, periodic review to avoid “privilege creep” (gradual accumulation of more rights and privileges than are really needed) is essential. But in general database designers and database administrators (DBAs) should grant only rights and privileges that users, applications, and services need, and no more than that. 2. Platform hardening Across the board, platform hardening requires a deep understanding of a platforms vulnerabilities and its attack surfaces, so that organizations can take pre-emptive measure to address known potential weaknesses. Among other things this means uninstalling or disabling features or services that you don’t need or use. It also means resolutely enforcing password discipline, especially when it comes to changing well-known passwords and their associated accounts (best to delete them if you don’t use them). Make sure all security controls that the database engine offers are enabled, and set to maximum tolerable levels. Checks on hardening success are covered further in the upcoming “monitoring and auditing” item. 3. Data protection Data and metadata for the database should be encrypted both in motion and at rest (and this applies to backups and snapshots, too). Data and meta-data should include security tags or classifications to permit full-blow security policies and protections to apply. Data protection also includes monitoring its access and use, export and exfiltration, especially wholesale copying activity not readily explained or understood. 4. Monitoring and auditing The old saying goes “If you don’t monitor it, you can’t measure it.” This applies equally to […]

Published February 17, 2021 WRITTEN BY MICHAEL SOLOMON Michael G. Solomon, PhD, CISSP, PMP, CISM, PenTest+, is a security, privacy, blockchain, and data science author, consultant, educator and speaker who specializes in leading organizations toward achieving and maintaining compliant and secure IT environments. The year 2020 will go down in history as being a year of uncomfortable changes. Just about everyone was forced to approach aspects of personal and professional life differently, from buying groceries to conducting business to maintaining safe interactions with others.  Fortunately, existing technology and service offerings allowed us to make adjustments and work through the changes. Zoom went from being a useful way of meeting virtually to a staple of business, education and social interactions. Likewise, the financial technology industry, often called fintech, expanded products and services to make contactless financial exchanges safer and more accessible. But as Fintech’s popularity grew in 2020, so did its attack surface. Fintech is the industry that provides individuals and businesses with the technology to carry out financial transactions. If you’ve ever sent someone a payment using Venmo, accepted a payment card using your smartphone, or applied for a loan online, you’ve consumed fintech services. In short, fintech’s goal is to leverage technology to compete with, or even replace, traditional financial services by making them cheaper, easier and more accessible. Smart devices and nearly universal internet access make the process of carrying out financial transactions in a socially distanced environment easy. But to keep fintech’s growth on track, cybersecurity has to stay ahead of the attackers. Fintech companies can’t afford to lose their customers’ trust. Let’s look at the most important cybersecurity trends in fintech that are needed to keep that trust. Technology reliance creates risk Any transition to a greater reliance on technology introduces risk. Additional devices and software can provide opportunities for attackers to find and leverage weaknesses. The COVID-19 pandemic punctuated the importance of touchless and socially distanced interactions. One of the most common pre-COVID-19 close-proximity interactions was paying for products and services. Although touchless and remote payment options were available prior to 2020, the pandemic made touchless payments a welcome feature. The number of suppliers and consumers who used touchless payments for the first time skyrocketed in 2020. Any industry-wide growth naturally attracts cybercriminals to prey on a new group of potential victims. According to a recent Fintech News article, attacks are up across the industry and included a 600% increase in phishing attempts and a 630% increase in cloud-based attacks. One reason for such large jumps is the increased use of personal devices to engage in financial transactions. Personal devices often aren’t managed to be as secure as many legacy devices owned by service providers. In addition to facing increased attack frequencies and veracity, many fintech companies are still in the process of digital transformation. While startups may begin their commercial lives with new infrastructure and software, most fintech companies still rely on some legacy devices and software. Each type, or layer, of software, devices and infrastructure means the potential for security vulnerabilities to exist. While it is possible to upgrade hardware devices with the latest models, software poses a bigger challenge. Even startups go through a software development process that results in code written using outdated standards or best practices. It isn’t possible to write […]