NEXT DIFI 2021: an overview

The last few weeks I’ve been busy with the various in-person events I attended (first Money20, then DigiPay2021), but I’m not complaining.  It’s energizing to speak in front of a live audience, while also reaching people online. On the 8th of October, I participated in Next Difi 2021, a hybrid event, dedicated to banking and fintech innovation, digital finance, cybersecurity, blockchain, and more.

I had the pleasure to moderate the Banking and fintech innovation, and cyber security and risk management panel. I enjoyed intriguing discussions with members of DSK, Acronis, and Sirma Business Consulting. They shared exciting insights, so make sure you watch the recording (link below 😉 ).

Moderating a panel with DSK, Acronis, and Sirma Business Consulting

I also participated in the Innovative Technologies, New Players, and Transformed Business Models panel, where I gave a presentation on Card Payments Security Standards. In particular, I discussed the PCI DSS, 3DS, and PIN security standards. I shared an overview of what they are, who needs them, and what common misconceptions most people have about them.

A big ‘thank you’ to b2b Media for organizing the event and for inviting me to participate. See you again on the Fifth Edition!

A full recording of Next Difi 2021 can be found here:

Author: Pavel Kaminsky, CEO of 7Security

DigiPay 2021 – Recap with Pavel Kaminsky

Picture: Digi Pay 2021

It’s confirmed: live events are slowly making their long-awaited comeback, and they have become so much better! Just a few weeks ago, we attended Money20/20, where we were hyped to see our fintech friends in person and to find many new ones.

To give a flying start to October, we also attended DigiPay Conference 2021 on the Ist of the month. DigiPay is the event when it comes to secure and convenient digital payments in Bulgaria, and was packed with professionals from the payment and banking sector, who brought us up to speed with the newest fraud and security trends in digital payments.

To begin with, the audience enjoyed a valuable panel on Open Banking, where banks and fintech companies discussed the challenges they meet in its face, the new solutions it presents, and the extent to which the payment sector is, or is not, utilizing the new opportunities.

Speakers then discussed digital payments in regards to identification and customer journey, where we observed valuable insights and statistics, as well as exciting innovations to look out for.

To get a more elaborate overview of the Real Time Fraud Prevention panel and the related Live Demonstrations panel, I sat down with their moderator – our CEO and Founder, Pavel Kaminsky.

DigiPay Pavel KaminskyPavel, overall, how did you find the organization of the event and the topics discussed?

I think it went great. We had around 100 people attending in person, and around 200 joining online. The panels were organized in a logical way, with enough time for discussion and for the audience to participate and ask questions. I noticed the panels are getting more exciting compared to previous years – the audience is more involved, the professionals – more detailed, and the issues raised – truly relevant. The moderators were handling things well and contributed to the discussions. Catching up with friends in-between panels was also awesome.

What about the panel you moderated?

It was the best one : )

Haha, no doubt there. Care to elaborate, though? Could you tell the readers more about the topics that were discussed?

Sure. I moderated Real Time Fraud Prevention panel. We had six speakers, who had prepared strong presentations that I observed with interest. We saw the newest trends in cybercrime when it comes to online payments, including the ways cybercriminals are bypassing the 3D password, which was added as a multi-factor authentication scheme, but is already exploited by cybercriminals.

Speakers then discussed how difficult it is to combat fraud in real time transactions, as instant payments = instant fraud, and how trying to prevent all fraud types and tools is an unrealistic approach. Instead, being able to adapt to current threats, adopting flexible case management, not relying solely on AI, and focusing on threats most relevant to one’s organization proves to be a much wiser strategy according to our speakers.

I was curious to also see a seminar, demonstrating a bank-level payment security program, which not only focuses on compliance and software but also on training employees and constantly testing their knowledge in practical ways. Such dedication to security is very impressive.

Towards the end of the panel, the audience found out how DeFi can be a more secure payment solution, mostly because there’s no centralized control, therefore no opportunity for human error. At the same time, we were reminded we shouldn’t see DeFi as 100% safe. Unfortunately, there are exploitation risks involved, that shouldn’t be underestimated.

To finish off, the panel concluded with a blockchain talk, discussing how blockchain solves many cybersecurity issues, but it presents new ones, and we already have examples of scams. This summarized the panel nicely – we concluded that there are no perfect solutions to solve all security issues, and while blockchain and other innovations can greatly reduce risk, it is never eliminated.

After that, I moderated a second panel with live demonstrations, where speakers gave the audience a live show for fraud prevention and showed them current trends in phishing attacks.

That was a nice summary, thank you. Besides the lack of a magical pill for payment security fraud, I noticed another ongoing theme that came up in all the talks – the human factor.

Yes, absolutely. All security and fraud prevention experts highlighted that we shouldn’t forget that on both ends of technology we have a human being. Compliance with established security standards and investing in good software solutions are important. However, focusing solely on getting more certificates and buying the most expensive product will not prevent your employee from making a costly mistake, or your customer from clicking on a fraudulent link.

Cybercriminals have realized for a long time now that trying to attack an organization is not easy, but attacking its customers often is. What came up over and over again throughout the panel is that many fintechs and banks fail to educate their employees and customers on how to recognize and report fraud, and how to carry out safe digital transactions.

As I mentioned, I was impressed by the dedication of some of the speakers, who presented us with the ways they keep their employees educated on cybersecurity. Unfortunately, overall I rarely see an organization that really focuses on the human factor when creating a security program. I sincerely hope the panel raised awareness on that.

Correct me if I’m wrong – this is a topic you have been discussing for a while now?

Yes, and I was glad it came up during the panel, because underestimating the human factor is a serious flaw of most payment organizations, and it’s vital to talk about it more. I’m more than happy to help all my clients achieve compliance with PCI DSS and consult them on how to follow the requirements, but it’s no less important for them to teach their users not to click on suspicious links and recognize and report fraud.

Indeed! Any final remarks?

I’d like to say thanks to Raya Lecheva – the main person to ‘blame’ for DigiPay, along with all the organizers and participants who made it happen. Being able to meet in person, discuss, network, and simply communicate with such inspirational professionals within our industry, was invaluable. I’m already looking forward to DigiPay 2022, bigger and better.

Author: Tanya Klyasova, Payment Security Enthusiast at 7Security

Protecting Telephone-Based Payment Card Data

For those businesses that deal with card data through mail order/telephone order (MOTO) transactions, particularly those conducting sales over the telephone, including the ones using VoIP solutions, The PCI Security Standards Council has come up with an update to the Information Supplement: Protecting Telephone-Based Payment Card Data in order to help these businesses secure card data in a manner that is consistent with PCI DSS.

This update emerges after over seven and a half years since the original document came into play in March 2011. It is definitely an improvement on the progenitor, inasmuch as it provides detail where said progenitor didn’t. And rightly so. Although, technically speaking, not much has changed and VoIP still runs over UDP, these days we are witnessing a new, tighter integration of these systems with everything else. Including but not limited to CRMs, billing, mailing, customer reward schemes, customer behavior tracking systems, etc.


It matters because these systems may have some sort of access to card data. Or, simply because when PCI DSS says your VoIP is in scope, you need to look at all these other systems that are connected to the network or can impact the security of the CDE, scratch your head, and think of magic words, such as “segmentation”.


Well, it is an unlikely channel, or rather, not overtly popular yet, but a channel nevertheless. UDP provides a nice stateless connection that can be (and is) used to disguise malicious code in streaming sessions. The reason we don’t hear much about these types of attacks is they probably just haven’t gained speed yet, or even worse, businesses are simply not aware they are happening.

Telephone systems touching card data have always been required to be in the scope of PCI DSS. Up until now, they have largely been neglected or avoided altogether.  In light of all we said so far, it is evident this needs to change. There are a number of pointers in the guide that are prone to raise an eyebrow, seemingly because they would ask the business to bear the brunt of some more stringent and resource-consuming alterations to technology, people, and process in their organizations.

Yet, with telephony systems in scope of PCI DSS, now more than ever, and the new detail provided in the November 2018 release of Supplement, owners and QSAs alike are faced with the need to come up with clever and doable ways to segment their VoIP systems, where possible, so they comply with PCI DSS without it costing them an arm and a leg.

What is Penetration Testing?

In the world of information security, Penetration Testing is the practice of checking and testing the organization’s network, servers, and services for possible loopholes and vulnerabilities that an attacker may exploit.

Penetration testers are called white hats. They perform hacking in ethical ways, without causing any damage to the computer system, thereby increasing the security perimeter of your organization.


Penetration Testing is required because it helps you highlight the flaws related to hardware and software system design and operation, and quite importantly, personnel readiness. Early identification helps protect the network. If the vulnerabilities aren’t identified early, then they become an easy intrusion point for the attacker.


Hacking refers to exploiting system vulnerabilities and compromising security controls to gain unauthorized or inappropriate access to the system resources. It involves modifying a system’s or an application’s features to achieve a goal outside of the creator’s original purpose.

Ethical hacking involves the use of hacking tools, tricks, and techniques to identify vulnerabilities so as to ensure system security. It focuses on simulating techniques used by attackers to verify the existence of exploitable vulnerabilities in system security.


Penetration testing will make sense if you want to achieve the following goals:

  • identify the threats facing an organization’s information assets;
  • reduce the organization’s IT security costs and provide a better Return On Security Investment (ROI);
  • provide the organization with assurance: a thorough and comprehensive assessment of organizational security covering policy, procedure, design, and implementation;
  • gain and maintain certification to an industry regulation;
  • adopt best practices by conforming to legal and industry regulations;
  • test and validate the efficiency of security protections and controls. May lead to changing or upgrading the existing infrastructure of software, hardware, or network design;
  • evaluate the efficiency of network security devices such as firewalls, routers, and web servers;
  • focus on high-severity vulnerabilities and emphasize application-level security issues to development teams and management;
  • provide a comprehensive approach of preparation steps that can be taken to prevent upcoming exploitation.


Network Services Test: One of the most common types of penetration tests. Involves finding target systems on the corporate network, searching for openings in their base operating systems and available network services, and exploiting them. Some of these tests take place remotely across the Internet, targeting the organization’s perimeter networks. Others are launched locally, from the target’s own business facilities, to assess the security of their internal network or the DMZ from within, seeking the kinds of vulnerabilities an internal user could find.

Web Application Test: Looks for security vulnerabilities in web-based applications and/or programs deployed and installed, operational, and running on target environment and resources.

Wireless Security Test: Involves discovering a target’s physical environment, searching for unauthorized wireless access points, or authorized wireless access points that have security weaknesses or other issues.

Social Engineering Test: Attempts to get a user to reveal sensitive information, such as a password or any other sensitive data. These tests are quite often conducted over the phone, targeting selected help desks, users or employees, evaluating processes, procedures, and user awareness and reaction readiness.


During penetration testing, a pentester analyzes all security measures currently employed by the organization, searching for any design weaknesses, technical flaws, and other critical or predefined by the organization’s decision-makers vulnerabilities. There are three classic ways penetration testing is performed:

  • Black Box testing – simulates an attack from someone who is unfamiliar with the system, establishing externally “available” backdoors or other perimeter-breach opportunities.
  • Grey Box testing – simulates an attacker that has partial knowledge about the system.
  • White Box testing – simulates an attacker that has knowledge about the system.

Once all the tests are conducted, the pen tester prepares a comprehensive report that includes:

  • tests conducted;
  • test results;
  • testing methodology;
  • all vulnerabilities found;
  • respective countermeasures.

Finally, the pentester delivers the report to the executive, management, technical, and all other authorized audiences.

Besides standard scenarios based on the type of Pentesting (white box, gray box, black box) and territory (network, application, wi-fi, etc.), it is good to engage in developing and implementing scenarios that are most relevant to your environment and in accordance with your specific information risks. For example, the concept can be changed to reflect the possible behavior of a particular type of perpetrator that is important to you, taking into account various starting points:

  • Externally located person: has no initial knowledge of your infrastructure. They start by going to the coffee shop next to your office, and commence hacking…
  • Your own employee: usually receives standard pre-configured IT tools (laptop, tablet, phone, etc.) and human access – email, corporate portal, etc. Testing can show you how far such person can go with these tools and what possible damage they can inflict.
  • Your business partner: has access to your ERP system, service provisioning team, etc. Again, testing will evaluate how much this person can roam around and beyond their authorized access, and what they can inflict.
  • Any other starting point that is important to you in relation to your business operations.

For each starting point, your testing vendor should be able to, on your command, apply all types and variations of pentesting.


The course of Penetration testing involves defining the Scope, signing an Agreement, and working on Recommendations.


Determine which critical systems are to be tested and prepared for mitigation under an attack scenario. The scope can be determined by an external certification or compliance requirement (PCI DSS, for example), or simply by what management has chosen in order to achieve adequate security assessment.



A formal expression of will and agreement to proceed with testing under the determined scope, timing, and method. This is followed by a comprehensive report on the risks facing information systems that provides the necessary insight and guidance to secure operations.




In order to proceed to the next step, you should review the report that contains test results and proposed recommendations, filter through risk management mechanisms and follow up with appropriate governance or integration endeavors.

Where to Start with Your Risk Management?

Understanding and identifying risks is essential to a well-built and sustainable business. Being in touch with the threats and the ways to counter them is essential for a safer working environment.

Risk Management is the most important instrument for Information Security Governance. It provides a framework for the assessment and successful management of risks. Sadly, this is something usually poorly done or even neglected completely by a surprisingly large number of organizations today. Risk management allows companies to devise and implement economically viable risk counter-measures. All activities involve risks, which are in turn a derivative of threats, vulnerabilities, and impact. Properly identifying weaknesses and assessing the associated risks is essential, and pays off in the long run.

What are the methods applied?

There’s a wide spectrum of methods used for Risk Management today. For the most part, these methods consist of the following elements, performed, more or less, in the following order:

  • Identify and list assets;
  • Identify and characterize threats before they appear;
  • Assess the vulnerability of critical assets to specific threats;
  • Determine the possibility of risk and the consequences it may bring;
  • Identify ways to reduce or even remove risks;
  • Prioritize measures based on a strategy.

The general principle

Looking at the ideal Risk Management, a prioritization process is followed whereby the risks with the greatest loss (or impact) and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled in descending order.

In practice, on the other hand, the process of assessing overall risk is complex. On one hand, we have to consider the resources used to mitigate risks with a high probability of occurrence but lower loss. On the other, we have the mitigation resources for risks with high loss but a lower probability of occurrence. Balancing between these resources can often be mishandled.


the choices for addressing assessed risks

The first one is acceptance – sometimes it is cheaper to leave an asset unprotected to a specific risk instead of spending the money required to protect it. Acceptance cannot be done without considering the risk itself and all options possible.

The second is mitigation – involves deciding on the implementation of countermeasures aimed at lowering the risk to an acceptable level (as illustrated with the algorithm below). One should keep in mind, it is not possible to mitigate the risk entirely.

Next is transference – this is usually referred to as the “insurance scenario.” A conscious decision to hire an external company to assume the risk in return for remuneration. Transference of risk is also achieved through outsourcing, with its own risks.

Finally, avoidance – when risks discovered are high or extreme and cannot be easily mitigated, avoiding the risk (and the project altogether) may be the best option. The math here is simple: if you stand more to lose from mitigating the risk than what you will earn from this project, then avoidance is the way to go.


Risk Management is at the heart of Information Security, because it provides an important instrument to balance and rationalize countermeasure expense with business success and expected Return On Investment (ROI).

When opting for one of the choices for dealing with risks, one has to take into account something called the  Annualized Loss Expectancy (ALE), which is the expected monetary loss that can be expected for an asset due to risk over a one year period. ALE is derived from Single Loss Expectancy (SLE) multiplied by the Annualized Rate of Occurrence (ARO) and can be used to directly analyze cost vs. benefit.

Regarding Risk Management, if spending on threat countermeasures is considerably higher than that risk’s ALE, then it may not be worth the investment. Or, in other words, one must evaluate the positive impact countermeasures will have on ROI by making sure the expense is not larger than the ALE.

Risk Management is meaningful only when decisions are made based on meaningful risk analysis, which in turn involves preliminary processes such as penetration testing, vulnerability assessment, and objective audit.

The stages in the risk management process:


  • Obtain necessary data access to business process and operations structure;
  • Identify and notify participants and decision-makers;
  • Identify and distribute scope, objectives, and requirements;

Identifying risks:

  • Ensure participation of appropriate staff and management in risk assessment;
  • Review scope, objectives, and process;
  • Conduct risk identification, consolidate related risks;

Assessing & prioritizing risks:

  • Identify and obtain consensus on impact, severity, probability;
  • Identify time window when risk could occur;
  • Assess and prioritize all existing risks;

Deciding on control options:

  • Identify mitigation options for each risk;
  • Identify risks to be accepted, avoided, transferred, or mitigated;
  • Assign plan operative instructions for avoided, transferred, or mitigated risks;
  • Establish/update risk database;

Establishing mitigation plans

  • Develop draft mitigation plans and resources;
  • Obtain manager review and approval of mitigation plans;
  • Ensure mitigation plan is funded, directed, and integrated;

Implementing mitigation plans

  • Finalize Risk Management plan;
  • Devise mechanisms to monitor triggers, cues, and mitigation;
  • Implement mitigation as authorized, funded, and scheduled;
  • Provide reporting on mitigation results and progress;

Monitoring mitigation plans

  • Periodically review mitigation plan results;
  • Stop or modify mitigation plans and resources;
  • Retire risks when appropriate;
  • Update risk database for mitigation process and retirement.