Security Incident Management, Data Protection & Privacy Best Practices | Edgar Pimenta (Group CISO @ YNV Group)

My name is Edgar Pimenta. I’m located in the north of Portugal, the beautiful city of Porto. In my early days, I started working as a developer and rapidly moved to internal audit in a telco company in Portugal, doing mainly systems audit. 

At the beginning of security audits, if we talk of over 20 years ago; security was not what it is today. So, I worked for around 20 years in highly regulated markets in the telco sector in the financial industry. 

Then, my previous company was a software as a service company. I joined that company not in the early days but when it was still a startup with a little over 2000 employees. I left five years later when it had more than 2000 workers and a valuation of 10 billion. There, I started a privacy and security program from scratch. We built a very mature security program and obtained numerous certifications. 

Most recently, I joined the YNV group as their Group CISO. The YNV group is a privately held company that operates in several fields, with the main one being tech talent. We work as a BPO and provide tech talent to our customers. But we also have some financial businesses and real estate ventures, including offices, hotels, and villas.   

I’ve work in highly regulated companies like telco and financial. And I have worked in startups. They are different cultures, but both have their pros and cons. I have worked in privacy for the last 15 to 20 years and was DPO at Talkdesk. 

True, But very honestly, I think that privacy is become a new field. It’s very hard to deal with all the privacy regulations you have worldwide. But I do believe that in the last four to five years, it was privacy that brought security to a whole new level. 

Because the fines are so big, companies say, hey, this is not worth taking the risks; we need to protect our customer data.  

And security has become a whole new thing because we need to protect our customer data, our personal data, our employee’s data, whatever, because if we don’t do it, it’s going to be a huge issue. 

And it’s not only the brand that is going to be affected. It’s the fines that you have from regulators and additional penalties that they can put on you. Restricting from processing data, storing processing data, etc. 

So, I truly believe that in the last four or five years, privacy has played a significant role in helping companies improve security.

Data protection and privacy is one of the main ones. Due to my background in privacy and because it’s a good strategy between both, I want to protect working data. Security and privacy are about protecting data.  

And when we’re talking about privacy and data protection, we’re talking about a lot of other things that can attach. 

For example, access management. Making sure people only access what they need is mandatory. Security, by default, is a very interesting concept that appeared a few years ago. But this is basically something that we already knew. That is, if you take security for the design phase, it’s much better to implement than when you’re already in the production phase. So security by default is also something that comes along with data classification data governance; all of that is handled with privacy.  

Then, actual pen testing. I do incident handling. The fact that I was attentive is good because when you’re incident handling, it is always very important to put yourself in the attacker’s shoes.    

And if you try to understand what they are doing, why are they doing that? What they can try to predict, what is their next step in terms of incident handling that is very, very important.  

I’ve also been involved in several incidents handling and the fact that when you have gone through those when you have a new one, okay, I’ve seen this, I see this vulnerability, I know what they’re doing. So, it definitely helps experience here.  

And I’m highly focused on processes- incident management, incident handling, all the preparation, all of that is making sure you have processes.  You may have, or you need people, or you need technology, but the process is fundamental to put everything in a cohesive way.  

And probably the third area, I would say, is between risk management and compliance. I do think compliance is a good baseline to help meet your security program. I don’t think compliance should be seen as, “Okay, let’s just do this because we need to do this, either because it’s a customer requirement or a legal requirement.”. 

Let’s take this as a great baseline to start improving or maturing our security programs. And I think compliance has an amazing part in this. I also see compliance as a business advantage. I think security and the business need to work together towards the improvement of the company.  

Security cannot live in a silo where they just, oh, I want to do this. And they don’t forget the business. They need to know the business. They need to help the business. I think security can also change, and compliance can also be seen as a security advantage.  

I’m a huge fan of continuous improvement. Things like ISO certifications mandated it. I’m an advocate for continuous improvement. There’s no perfect security program. You need always to keep improving. The fact that you’re improving makes you understand what flaws you have and what risks you have, and now work towards mitigating and solving them. And that cycle of improvement, I think it’s fundamental to mature any security programs. Actually, it works in a lot of things. Security is one of them.  

Some things are similar and quite different, not because of the application security itself but because of the ecosystem. 

Telcos and financial markets- High-regulated markets by default. They are more risk averse. Everything is different. And a lot of the applications in the ecosystem of those companies, you have home banking, mobile applications, but there’s a lot of internal applications. Often, they rely on a lot of the holistic security you put on them, meaning network security, etc. So, to a certain point, they may not be that exposed. I’m excluding the mobile applications for banking.  

And when you go to the SaaS, it’s quite the opposite. You are developing applications that you want to put either as an API or with the user interface; you want to put it out there, and you want it to be in the cloud, and you want it to be open to everyone. 

So, in terms of threats, you are much more exposed to a certain point. While in the telco and financial, you may not be that exposed, but at the same time, you are in a sector that is much more a target because that’s where money is, mainly in the financial sector. So you have those threat landscapes that are different. 

Then, when it comes to dealing with application security, there’s also the technology that you have. A lot of telcos and financials have more legacy systems. Of course, in the last few years, many have been operating more in more recent technologies, but they have more legacy technologies, and it’s working well. This is working. I prefer not to change it. 

At the same time, the development process is also changing, but it is much more waterfall. Every change needed to update security patches, etc., was harder. 

In SaaS, it’s different. If you fail fast, you also correct quickly. You use more recent technologies, and often, you can have very fast development timelines to solve the issues right. The concern I see, and this is a bit of criticism between two different development approaches, is in the waterfall. 

Sometimes, you can put all the security or a lot of security requirements in the beginning and make sure they are implemented right in a perfect world in agile; a lot of teams develop MVP (Minimum viable product). 

And when that product is working, we put it into production, start selling it, and now we need to go to another one. And we didn’t put all the security we required for the MVP because it was an MVP. You don’t invest a lot in security in MVP and try to save time on security in MVP. 

And it’s a paradox because you know it’s much better if you do it initially. But if you’re doing an MVP, you want something working. So you’re not going to spend a lot of time in security. But you should. 

And then, when it comes to production, it’s done. I’m selling this to customers. I don’t want to make a lot of changes now, and I need to do other MVPs. So, it’s a question of bandwidth that all companies face. 

So that is one of the challenges that we have. It’s not regarding only culture. What lies behind the typical culture of software as a service? Of course, more mature companies like software as a service company have solved this problem. 

But if you are initially talking about startups, it is what it is. And it’s always from a security perspective to try to push security in those MVPs. So, it’s different. Each company is different. It depends on how exposed you are, and what implications you have that are external or internal. But there are still differences. 

I think SaaS is all about speed; you have hit the nail on the head, whereas in regulated environments like large enterprises, telecoms, and financial services, it is about being risk averse and having regulatory frameworks driving your entire protocol and mandate. And right now, in this group company that we are working out, there’s a lot of legacy and disparate systems that we probably have to deal with. which presents its own challenges as well. 

There are always some issues… actually, you don’t have a lot of legacy systems. We are quite a recent company, to be honest, but it’s a different ecosystem, right? It’s a more complex ecosystem. We have a lot of on-prem stuff, and that brings back everything. It has pros and cons. But we also rely on some cloud providers and software as service providers. In that case, some of the responsibility is not on our side; it is on our provider’s side, but we need to make sure that we put some controls over them to make sure that they don’t fall into those issues that sometimes SaaS companies face. 

And I think what is also happening is all the three things that you mentioned in a new age SaaS company that’s coming under one, like, for example, I mean here you have new age FinTech SaaS companies that are aggregating different kinds of services and pieces and open that is in India, there is this concept of open banking API. Then, there is this OCN (Open Credit Network) where you can quickly disburse loans for new-to-credit systems based on data and profiling. So, there is speed and aggregation of different technologies, which will have disparate systems, not necessarily legacy but new-age systems combining them and working in a FinTech or telecom market. So, you will have a mix of all these in the SaaS ecosystem.   

I agree with you because we see FinTech companies coming up right now, not only because of crypto but also because of open banking; as you mentioned, we also have similar things here in Portugal, and that will create a fascinating mixture of cultures. You’re putting together speed and agility. Let’s fail fast, but let’s also develop quickly. And at the same time, you’re working with highly regulated markets, very sensitive information, and a lot of privacy concerns. And this is a huge challenge. And a lot of companies that are, if not all, companies that work in that space will need to address those challenges quickly. And there will be a time when regulators will understand that, eventually, they need to do their regulation differently and fix that first because the old ways eventually are not fast enough. 

And at the same time, some companies will understand what they need. I’m not saying they are not right, but they need to take security even further than the regulator asks. Because at a certain point, just compliant will never be enough, like I said in the beginning. You need to use the need to comply, build a baseline, and start growing from there. And that’s something in a culture that is still shifting because many companies still need to comply. So, I’m okay, I’m complying with this. It’s then regulatory standards, and I’m doing this. You need to go further because regulators will understand all these companies are different. We need to be more demanding with them. And if they are not prepared, they will struggle for sure. 

I’m a massive fan of using the NIST approach for incident management. You need to have two very important components. The first one is preparedness. And this is something we heard a lot. Oh, you need to be prepared. Okay. I know. I need to be prepared. 

But when you have your first serious incident, you understand that you are not prepared or prepared enough; that’s when you learn what needs to be prepared. 

Because you may have a lot of things, but when problems happen, that’s when you will understand. Oh, after all, everything that I did was eventually not enough. Even if you do a lot, more than preparedness is needed, and even if you prepare a lot and have a lot of experience, there will always be things that you need more time to be ready for.  

So, you need to be able to adapt very quickly. You need to adapt and understand what’s happening. I do remember an incident from several years ago. Some information from the company was exfiltrated, and we were being blackmailed to pay if they didn’t want the information to be made public. And of course, when we got that, we got what’s happening? We tried to understand. And then we started looking at the data, and we realized that some of the data they sent a sample was wrong. 

It was not an actual exfiltration of data. They collected some data, put it together, and tried pretending to be an exfiltration data. All is not to make assumptions. Of course, we tried to understand if there was any exfiltration, etc., but don’t assume everything is happening as you think. 

Try to understand exactly what, look at things that you wouldn’t look normally. I think having the capacity to be on the bad actor side and try to think, 

• Why am I doing this right? 
• What I’m trying to accomplish? 
• Why are they doing it? 

Sometimes, it’s essential to try to anticipate, as I already mentioned, but also to try to understand what’s happening, So definitely preparedness don’t make any assumptions. Try to understand what’s happening. And when you do that, try not to spoil everything. 

You know that old case of when you had malware in the old days; the first thing you do is turn off the laptop. It goes off, but then you lose everything: forensics, etc. So, be prepared for assumptions. And it’s also very important, and this is part of the preparedness: know your architecture, assets, and crown jewels very well. 

Because in an incident, that’s not the moment where you want to collect all that information. It becomes difficult if you’re trying to collect all that information at that time. And that’s also been in these situations. I’m not discussing any incident for obvious reasons, but I can use it. 

Don’t forget that there are very good and, fortunately, very good bad actors out there. But there’s also a lot of not very good bad actors. They are just aimy. And if they aim for many companies, if a small percentage of them fall into that scheme, it works for them. That’s the idea. 

The one thing I would also mention on preparedness, and I’m also on both sides, is audit logging. So it’s so good when you have an incident. And you start going through your systems or your CRM or whatever, and you realize you have traceability to understand what happened. It gives you a sense of accomplishment and warmth.  

On the other side, if you don’t have that right and you say, hey, this happened, I’m trying to figure out how this happened, and there are no audit logs, or they are fault or not enough. You know, the frustration is huge. And you feel like your hands are tied. There’s nothing you can do because there are no audit logs. And that is, for me, part of the preparedness, ensuring you have visibility and monitoring everything already, if not everything because 100% is always very hard to achieve or costly. 

At least you’re covering the most critical ones. In terms of preparedness and knowing where you have your data, what are your ground rules?  

When you’re talking about audit logs, you’re touching everything. For example, you need to ensure proper access management with unique identities. You do not have people sharing passwords or sharing users because accountability is lost. And if you don’t understand that before the incident, when the incident comes, you may find yourself in despair, saying, why didn’t we have this in place? It was so easy. 

Technology is fundamental when discussing those three components: process, technology, and people. You need to have technology. But if you have a lot of technology but don’t have the people or the processes to deal with it, improve it, or take the best approach to it. So, you’re just saying you’re having it. You’re not doing the best.  E.g. going to the threat monitoring, you still don’t have the internal capability to deal with the threats already defined by the threat monitoring software. It isn’t the best approach. 

For me, WAF for applications is a must-have; the cost-benefit you can have is amazing and brings you many benefits. To protect a lot of typical threats like OWASP Top 10, etc. You can build on WAF with DDoS protection, virtual patching, etc. So WAF is important; DAST and SAST, for example, are essential. 

But how mature is the development lifecycle? How mature is the back correction lifecycle? Because okay, I have a DAST, I have SAST, I have identified many things. I don’t have the team or the processes to start solving that. So, you have technology that is producing a lot, but you’re unable to handle all that. So, you need to mature your development and back correction processes to take advantage of that DAST & SAST. 

And virtual patching can help you there. At the same time, it may have a con, which is mainly the developer’s cultural thinking. We have virtual patching, and now we have bugs. But instead of fixing bugs, why don’t we apply a virtual patching? And virtual patching should not be seen as a final solution. 

It’s a mitigating risk solution that helps sometimes. But in the end, you need to solve the root cause. You cannot just apply virtual patching to everything and not solve the root causes; if not, it will be the same problem one day. You have so many virtual patching to apply that there’s no bandwidth to solve and use all the virtual patching. And it’s becoming too complex, 

So, it needs to be a temporary solution that helps reduce the risk during higher threats or critical vulnerabilities that cannot be patched by then. I’m a huge fan of virtual patching; it is very important and can help a lot, but it should not be seen as Okay, now, we have a virtual patch, the vulnerability management is done, and patch management is done because we have a virtual patch.