Watch to learn when PCI DSS 4.0 may be released and what we know so far about expected changes.
Having issues accessing the video above? Watch the video here.
Listen to VP of Assessments, Gary Glover (CISSP, CISA, QSA, PA-QSA) speak about the upcoming release of PCI DSS 4.0. As the PCI Council requests more involvement from both the merchant payment community and the Qualified Security Assessors (QSAs), the standard continues to improve. Gary covers:
This presentation was part of our recent virtual conference SecurityMetrics Summit, where 24 experts discuss the latest news and best practices for cybersecurity, PCI compliance, and other compliance mandates in 18 presentations.
With over 20 years’ experience in cybersecurity and PCI DSS compliance, SecurityMetrics Summit presents insights from technology leaders and cybersecurity experts with sessions that discuss:
To learn more about PCI 4.0, check out our PCI DSS v4.0: The Future of the Payment Card Industry Security Standard blog.
Hello. I'm Gary Glover, and I'm the vice president of assessments here at SecurityMetrics. And I'm gonna be talking to you today about PCI DSS four dot o, the future of PCI DSS compliance.
Just to start off, just a little bit about myself. I've been here at Security Metrics for about fifteen years, and, that's pretty much from the beginning of of PCI DSS as a standard.
So and been conducting assessments, since that time. So I've had a little bit of experience watching the standard change a little bit over time.
For SecurityMetrics, I started out as an aerospace engineer at McDonnell Douglas, California and then moved into software development for a few companies. And now I'm here as a security analyst for SecurityMetrics.
And, hopefully, this career sticks. It's my third one, so it's been really great. And I absolutely love working here at SecurityMetrics and working with the people on our team.
So before we get down into the nitty gritty, just a little bit about what SecurityMetrics, is kind of all about. And, one thing I think that really gives me a lot of satisfaction as a security analyst here at SecurityMetrics is the ability to work with people, as they improve their data security.
And, hopefully, the result then is less security breaches and a little bit easier pathways to any kind of regulatory compliance to be able to close those gaps. Again, security first, compliance second is the right way to handle things.
So, it's really great continued being in this in this industry because, it's fun when somebody starts an assessment and then ends an assessment in a more stronger, secure position when they started. To me, you know, really, that's what it's all about.
Alrighty. So as we move on here, we've got a couple of things we're gonna try to cover today. So we're gonna be talking about why PCI DSS four dot o, why now? Kind of the form and the focus of PCI DSS, that the version four dot o that's coming up. Any, expected and possible changes that we may see in four dot o, and then I'll kinda sum up. So let's go on and get right to it.
First off, why? Why is this a major revision?
To go back a little bit in history, there's been nine revisions, if I count it correctly, since two thousand four, which was one dot o, and, to the current PCI DSS version. And currently, we're at three dot two dot one.
So that illustrates, obviously, that this is a dynamic standard, and it's something that changes over time nine times in fifteen years or so.
And, so it's something that that we're really trying to do to keep up with industry changes. The council is really, making sure that they're staying tuned in to what's really going on out there, making sure that we know what bad actors are doing and, how to continue to fight against their arsenals of attack.
So change is a good thing, and and I guess that's kind of a general life lesson, isn't it? Anyway, as we, look at PCI DSS, I know a lot of people have said over the time over time, and we've heard that this is a mature standard, and and how can it be changing now if it's a mature standard?
Rest assured, it's not really gonna be a totally new standard. It will be familiar to you. There's gonna be the same basic security goals, and the same twelve sections, the same focus of each of those sections. So it'll seem familiar.
There will be, some changes in focus maybe in some of the sections, maybe some additions and corrections to the standard where needed.
And to so that you know, all of these changes have been driven by, some really important things. Number one is industry feedback.
And, these are, you know, information and and comments from merchants, participating organizations, card brands, QSAs, everybody trying to make sure that, you know, we're getting the feedback in so that that the standard can be changed in good ways.
It's really great to know that the PCI Council does listen to the community, and then they actually do respond. There's been a lot of changes, obviously, in payments, technologies and payment methodologies and and, processes. So those things need to be updated over time.
Obviously, as these as bad guys we mentioned earlier, as bad guys get get better at doing their stuff, we need some, new security items and new new areas to cover.
So, anyway, a lot of the changes you're gonna see fall into kinda two main categories. Really, just updating and clarifying, as I mentioned before, existing requirements, fixing wording, making sure they're easy to understand.
And number two, there will be some addition of new requirements as we've seen in other versions of PCI DSS as they've come out.
Some of those may be future dated. In other words, they'll give you a period of time to to transition to the new requirement. So, anyway, what's the current status then of PCI DSS four dot o?
So this this round, this this revision has been a really interesting and a great experience for me as a QSA.
The council has really gotten the community involved in version four dot o, and and I think that's been they've done just an incredible job. We're we're involved earlier on in the process. There's going to be a number of RFC or request for for comment rounds. We finished round one, and round two is gonna be starting soon. In round one, over three thousand feedback items, were were provided to the council, and they're going through each and every one of those.
Interestingly, about forty percent of those came from the merchant community community themselves. So that's important to see that it's the the real big chunk of of users out there are the merchants, the people that are actually taking their credit card numbers.
So and always, also, QSA companies are involved in providing active feedback on how to actually validate and what things are difficult for customers. Those comments are being folded in and also processed for the for the standard. It's been, again, one of the first times we've been asked as QSAs to provide a feedback and a change of a standard. So that's been a really great and a and a fulfilling process.
Some examples of some of the feedback that the council has have been given are, some stuff in in requirement four, which is protection of all transmission of cardholder data. So that, we'll talk about that a little bit later, but there may be some changes in in how how internal transmission of cardholder data goes. There's been a lot of comments on in requirement eight about password and authentication, length, history, change frequency. We wanna make sure that those are aligned with the current industry guidance coming from NIST and other places.
Comments were received on the, potentially, the ability to to compare a list of new passwords or a new password against a list of known bad passwords and provide feedback to people who are setting the password saying that that's not a good one. They're gonna be talking about, multifactor authentication.
A lot of comments received about that.
Authenticated scanning were, some topics that they they got comments on.
The process of annual risk assessments, how can that be improved? Should it be made a little bit more easy to understand?
And methods for data discovery and data leak prevention were also areas of comments received in their feedback.
So with all of that said, the standard four dot o, the new standard that we're coming out, is still changing, and it may change, right up until the very last, release.
So everything we talk about today is kind of like previewing and stuff that we might be seeing, but stay tuned to the process to keep your main focus on PCI compliance to three dot two dot one for now, and make sure you just follow kind of the progress, of four dot o as it's going on. So you keep one ear to the future, but make sure you're keeping both feet on the ground in three dot two dot one. So let's talk a little bit about the development timeline. And you can see here we've got a a timeline showing, you know, from twenty nineteen out into q four of twenty twenty one. You can see where we are at q three in twenty twenty. Just smack dab in the middle of the blue bar down below, which is the kind of the RFC, the request for comment feedback area.
And you can see that we have the, second RFC round probably coming somewhere pretty soon here, maybe October, November, something like that, starting off in this year. And then that'll hopefully be ran you know, cleaned up by q one, and then they'll be incorporating those comments. And and you can see that that by q two around, they'll be able to have four dot o standard itself completed for its official release. Now at that time, it doesn't mean that all the other supporting and ancillary documents are updated, things like SAQs and ROC templates and any kind of program documents and things like that. Those will you know, the council will be working on those furiously as soon as four point zero is completed to try to get those done by q four of twenty twenty one. There's a lot of stuff that needs to be done.
And, the council is very focused on making sure that Ford Auto is just the best thing that can be possibly done right now given the feedback and current, information that they're gathering from the community. So it's really great.
So there will be, you know, a transition time, which we're gonna talk about next.
So just stay with me here, and we'll talk about that. So now we've expanded timeline from twenty twenty. We've kinda moved it over. You can see we are here down there at the very beginning to the left in q three of twenty twenty, and it goes all the way out to q four of twenty twenty four.
So, you can see by the you know, where PCI DSS is completed, when the supporting documents are delivered there. And then when PCI DSS three dot two dot one is retired clear in q two of twenty twenty three, that does leave about eighteen months of time between when all the documents are prepared and ready and released so you can have them.
So eighteen months till when three dot two dot one will be retired. So it'll be plenty of time to learn, to transition, and and figure all that out. So, hopefully, that'll help you breathe just a little bit easier. Dates may change a little bit, but I think, essentially, it'll be pretty close there. There's gonna be plenty of time. Everything's gonna be okay.
You also see kind of a dark blue line down or dark blue kind of, arrow set down there underneath. That is indicating that there will be some future dated requirements, which which they've done many times in the past. They'll have them you know, this is a best practice for now until, you know, as you see here, q one of twenty twenty four, then all of the new future data requirements will have to be followed.
So, the sooner you then you begin working on those future data requirements, the better. So you don't procrastinate till the end. Looks like around somewhere in twenty twenty two, maybe the first part of twenty twenty two, you can actually begin assessing against PCI DSS four dot o if you believe that your organization is ready for that. And, again, something to be prepared for and and to work on as soon as you possibly can. But, again, don't worry about it. You got plenty of time.
So here's a quick quote from, Lauren Holloway from the PCI Council, and it covers some of the supporting documents. Let's go ahead and read that. Lauren said updates to supporting documents, including FAQs, report on compliance template, the PCI DSS glossary, prioritized approach.
All those things are part of the revision cycle. We will begin working on updates to all supporting documentation to align them with PCI DSS four dot o later this year. We're planning to have these documents completed and ready for release within a few months of the final release of four dot o. So as I said before, the council is really committed to getting these documents all aligned and ready as soon as possible, but it's a big job.
Alright. So that kinda gets us into why and how come there's a four dot o.
Now let's talk about some of the things that the form and maybe the focuses of four dot o are gonna go to the stuff that we currently know. It's not gonna be everything, and it's not a tell all, but it's just gonna be some kind of clues and hints about what's coming.
So here's what we do know now about four dot o. The biggest change you're gonna see in this update is that all of the requirements have been kinda rewritten and redesigned to focus on security objectives rather than just a specifically written word requirement.
I think the cool thing about this is this is gonna allow them to change their writing style a little bit to more of an outcome based statement that really focuses on security controls rather than a a set, you know, written down requirement that you have to meet word for word.
So the language I think you'll see in some of the requirements, they'll change from what must be implemented to be compliant to really kinda what the endgame security outcome is or needs to be from the requirement.
I think this is really gonna be, important for some new customized approaches to validation that we're gonna talk about a little bit later.
The other thing that they've done is, obviously, gonna continue to enhance that guidance column, the last column of the standard as it's released that will be explaining kind of the requirements and the testing procedures, all those things that need to happen. So those are always constantly being updated and made more clear, and you'll see those changes there.
So the changes, are gonna be focused in in really four main areas.
The first one being, let's ensure that the standard continues to meet the needs of the payment industry.
Then we obviously want to make sure that we're promoting security as a continuous process. It's not just a one and done checkbox thing. We want people to be as always working on security all the time.
There'll be some changes in the enhanced. There'll be some validation methods that are gonna be enhanced and changed. There may be some new methods and new procedures, and also flexibility to support additional validation, methodologies. So we're gonna talk about each of these areas, a little bit as a little bit here. So here we go into those changes. So first off, ensuring that the four dot o meets the payment industry needs.
As we mentioned at the very beginning, the standard really has been something that's been evolving over the last fifteen years, and it needs to to make sure that PCI DSS stays relevant.
In the next couple of slides, we're gonna go over quickly some of those areas where the standard is evolving.
So first off, we've got scoping. You know, over the years, you've seen lots of changes in the scoping areas and more guidance given. There's been focus groups on on scoping and trying to figure out the best guidance there. There's been informational supplements coming out.
So some of all of that stuff is gonna be a little bit more integrated as we hear. And instead of just being something that's written at the very beginning in a section on scoping, it's going to try to do some of that scoping guidance all right in the requirements and, helping to clarify what systems need to be expected inspected. And so those validation requirements will probably be expanded a little bit more to cover those, confirmation of PCI DSS scope. So you'll see some changes there.
And, again, plenty of time to work on those changes. I don't think it's gonna be an amazing all of a sudden, everything in the world is in scope. It's just gonna be trying to clarify a little bit better what we already know, making sure that people understand even better, as we as QSA's often run into scoping kind of, how do you say it, not agreeing always on exactly the right scope. So, hopefully, some of those things are gonna be cleaned up and made easier for the whole industry.
Let's see. So in four point o, the next one is under data transmission. We expect to see, four point o moving towards increasing the security of data transmission even inside the card network. So that's really meant to further secure card data in motion because of the attack vectors that really are being seen right now inside your networks as the card brands are doing forensics and and we're looking at the actual compromise vectors. We're seeing that this is a real problem, so you can expect to see some requirements in data transmission. Again, it's just incrementally adding a little bit more each time so that you can increase your security posture. Remember, the PCA standard is the floor, not the ceiling to security.
So, we also think that there'll be an area of evolution on phishing and social engineering. The council recognizing that that's a really big vector for attack. They announced there will be some treatment of these topics in four dot o.
Risk assessments. This has always been kind of a one liner or two liner thing in the very last section of the PCI DSS. I think we're gonna see a lot more, expansion about how and what and some of the expectations, a lot more detail in that area.
You'll probably see additional requirements being added to clear up some of those vagueness of what the risk assessment process is.
So there'll be some more things there, but I I do think that that's gonna be an improvement because many people are just MQSA's too are kinda going, well, you know, what really is the best thing for you to be doing there and to prove that you have done a risk assessment? So there'll be some great guidance that we'll see there.
Authentication.
Now there's a lot of things going on in the industry right now about different methods of authentication, about making sure passwords and and password length and periodic change guidelines and changes to multifactor authentication.
We wanna make sure that we're following those industry best practices that are coming out through NIST and other people. So the proposed revisions will will probably be covering some requirements on passwords and other things that they may accommodate different authentication options. So we're looking for some of that detail.
Finally, the council has mentioned that they really want to include, cloud technology a lot more clearly and where it may apply within the standard. We're also gonna be, expecting to see some revisions of appendix a one, which in the past has been shared hosting providers, which was a thing that you did to share a Linux machine, you know, or Unix machine in the way past. Now those that type of behavior isn't done so much. It's more of a cloud virtual area. So I think a section, appendix a one is gonna be really improved and looked at so that that will be updated for the cloud world and those technologies in mind.
So the next focus area then change area was security as a continuous process.
I think you're gonna expect in in four dot o to see clearly, some more coverage of how we develop habits for security best practices, long term things. Security is a continuous process.
So the intent here will probably be that the PCID assess requirements, how do you show that they're being followed year round rather than just an annual assessment period? There may be changes in sampling guidance, or methods of gathering information. I don't know.
So watch for some of that stuff and, you know, over time, be thinking, how can I make this instead of just trying to get through an audit one time during a year and ticking all the check boxes to really making security a continuous thing is just part of our culture, part of the culture of of a company?
You'll probably also see some changes in the way that people need to confirm their environment scope and, critical security controls, maybe more testing, like I said, and maybe more stringent ways of making sure that you confirmed your scope, and it may happen multiple times during the year.
Okay. Moving on to the next topic, and that is enhancing the validation methods and procedures.
Earlier on, we talked about, you know, when the SAQs and and everything will come out as you noticed, and I've circled that here on this timeline.
In q four of twenty twenty one, that's when we expect to see the FAQs, the program docs, and all that kind of stuff.
So I know a lot of people, especially smaller merchants, are gonna be worried about any changes to the SAQ forms. They don't really know how much they may or may not change for four dot o. So really don't worry about this right now. Just be patient.
Make sure you're focused on what you're doing now. There may be some changes in the SAQs themselves and maybe even the number of SAQs that are being used for validation. We just don't really know. And, again, the council is focused on four dot o right now, developing that standard first, and we have full confidence that they'll work quickly and carefully on the new SAQs.
Again, maybe even getting some feedback from the industry at that time. Not sure.
Here's what we do know a little bit about kind of the the validation process and the things the council has said. They do definitely wanna make sure all new validation methods, like SAQs, etcetera, will mesh complete with the four dot o release.
That's why they're being so careful about finishing and and getting a super tight and careful and clear four dot o finished up before they move on, to those. It's really great to know that the council is seeking feedback from the community before these new methods are released.
So make sure that if you're a participating organization or a QSA, be sure to get involved in these RFC processes that really help finalize four dot o and any kind of ancillary documents that they may send out for comment.
Make sure that our voices are hear heard here in the community, because they really are they really are using our feedback. I've been really amazed and and feel really great about how they're incorporating our comments.
Now we also know that card brands may modify or enhance any kind of processes for validation over time. We expect these to probably be pretty minor changes, if any. So, again, feel confident the council and the card brands are really trying to make this a better process and improve the compliance validation process, not making it impossible to actually do.
K. So kind of the last area is is, flexible validation. What does that really kind of mean?
In the past and and currently in three dot two dot one, there's what what's called a traditional method or traditional defined approach to validation, and that's definitely not going away. The PCI four dot o will be written in such a way that you can read the requirement and you can have a testing procedure and you can just meet the requirement just like that, just like it it's been doing been done today and is being done today. That's not going away.
There will be an additional, customized approach methodology, that is being proposed and and worked on.
And some of that is because of the, you know, industry has really requested a little bit more flexibility in the standard. So, you still obviously have to meet the intent of the requirement, but maybe there'll be some some room for conducting some. We're gonna be talking about that a little bit later here.
So currently, what happens is when a company can't exactly meet a PCI DSS requirement, you look at defining a compensated control. But often, those are considered kind of a temporary solution until you can meet their requirement in the right way. So, hopefully, the customized approach will help in this area and provide a more long term and a permanent and and, more feel good approach to different and equivalent ways of securing, sensitive data.
Interestingly, you can use a combination of both of these options in one report.
So you can have one requirement being met in the traditional way. The next one down, you can be doing a different way and so on combined all through the whole report on compliance. So that's very flexible. But, again, with a lot of flexibility, sometimes comes a lot of work, and we'll talk about that a little bit more.
Here's a quote by Emma Sutcliffe, who is the senior vice president of standards at the council. She said, quote, the draft of the PCI DSS version four dot o includes intent statements specifically linking each requirement to a security outcome.
The intent statements directly support the new customized validation approach by clearly identifying the security outcome that customized implementations are required to meet.
So this again is a mention of that linking of an intent and objectives, what really makes, the customized approach possible.
So So many people may have kinda be wondering, so what happens to compensating controls?
Again, we mentioned that they're always been kinda seen as a temporary fix until you can meet the real requirement, and many have felt that they represent kind of a subpar PCI DSS compliance method. So the use of this customized validation approach in four dot o will take the place of commsending controls controls. So commsending controls will be discontinued and replaced by this customized approach method.
Let's learn a little bit more about that.
So what are some of the details? A lot of times, you know, even even now when we're working with people on a on an assessment, they'll say, well, I have a different approach to that security control.
What can I do about it? What can you how can you help me? How can we work together on this? And in the past, it really has been, well, you can we can set up a Commsay and control and and and, hopefully, you can work on doing whatever over over time and get it better.
So, again, the first thing you have to do is meet the original intent even in a customized approach control of the and and the objective, the security objective has to be met.
Part of this process is going to be having to determine the risks of any kind of alternative implementation or security control or maybe a set of controls.
That may sound easy, but, typically, this is a a long process intended for people who really for groups and teams that really understand the risk assessment process.
So this is really most suited for organizations with miss sorry, mature security and risk assessment processes already in place.
Using the customized approach will require a lot, and I mean a lot of documentation upfront.
And a lot of that is on most of the the the lion's share of that is on the the, entity side, not on the QSI QSA side. So, let's get a little bit more detail on that.
This chart shows then some of the information and some of the stuff that's been presented by the council before. You may have seen it. But just to go over it again, you can see the light blue portion of the upper bar there is is the entity or the person or the the company not the person. The company being assessed for security.
So you can see that under there, the responsibility of the entity being assessed is to provide documentation that describes all any kind of customized security controls or implementation.
They then have to do all the legwork to provide accurate documentation, carefully document all the reasons why it will meet the intent of the original objectives and the original requirements, and then provide a detailed risk assessment, a documented risk assessment of the proposed solution.
Then you package all that set of documents and and work together, present it to an assessor for review. And that's where the blue the darker blue portion of the of the process begins where the assessor then reviews that information.
Perhaps there's some questions going back and forth about it, to either improve or or change or whatever to to make sure that both parties are happy about it. So there's be an iteration process between those steps. And then once you're all happy about, okay, we believe that this risk assessment, this new method is really gonna meet the intent, and, the assessor then needs to derive testing procedures that will be based on that information provided. And then he will have then have to document he or she will have to document the details of any testing procedures and the results, in the report on compliance.
So, this new validation method really will probably most likely result in a more more work upfront for an entity to really prepare for it, as you can see. It's gonna be harder in general, not easier. There's gonna be a large dependence on the resources of the entities that are being tested. It's not something you just say to the QSA after asking that question, how can I do this?
How can I how can I do a different thing than what the requirement is, let's say, and I wanna meet the objective?
It's not something you say, QSA, figure this out. It's, I will figure this out to the best of my ability, then work with the QSA on this solution.
At the end of this process, the big advantage will be that you'll have a defined and a permanent solution for compliance validation into the future.
So that's really kinda different from the previous, as we've mentioned, temporary compensated controls feeling that's been in the past.
So this new customized approach methodology does, in fact, offer more validation flexibility, but you can see there's a catch. And that catch is that there's a lot of work that needs to be done and agreed upon between an entity and a QSA.
We don't believe this will probably be one of the most common validation approaches being used by everybody for four dot o compliance.
And you may ask yourself why, and you can see the phrase there at the bottom. Simply stated, it's great flexibility comes great responsibility.
Many organizations may not be able to meet the rigor of this new validation.
Okay. So summary of the customized approach.
As I said before, it's not gonna be the simpler path. It's gonna be a more difficult path, but it may have some advantages for the hardy.
An assessment using the customized approach, will will most likely cost more than assessment using the defined approach. And that's because of the increased activities both on your on the assessed entity side, but also it may cost, you know, more for the the back and forth development of any processes. It will just take more time.
So make sure that you're looking for a QSA with the depth and years of experience necessary to validate any of these custom controls to meet those make those appropriate testing procedures. Now when it's all done, it may end up being a more cost effective method, you know, when all aspects are considered. But you have to understand and make sure your management understands that going this route will probably result in higher costs upfront.
We are missing this. So so one thing, you know, you can see there in this book, I doubt that this method will be able to be used with the FAQs.
I don't really know yet. We haven't seen the FAQs. The council hasn't really made any comments. But I think it'll be very difficult to do a self assessment on this process without a security profession involved. I don't know if there will be a a way to get a QSA involved in an FAQ for this type of a thing.
I would probably assume that SAQs won't have, any kind of customized approach possible, but we'll see.
And, remember again, don't assume that the QSA will do it all. You just hand it over to them to figure it out. This is really a team process.
So let's sum up kind of all the things that we've been talking here about today.
Number one, the PCI DSS four auto changes are not final, And everything can still move a little bit, so just make sure you stay tuned.
Some of my comments that I've said today may end up turning out to be false in the long run. So, you know, don't shoot the messenger on that one. Just stay tuned. If you're a participant in your organization, please consider getting involved in the next RFC round coming up at the end of twenty twenty. This way, you're gonna know exactly what's going on, what the standard is gonna look like, and how you might be able to provide feedback.
And, again, let me assure you, the sky is not falling. Keep calm. It's gonna be all okay. My dad used to say, hold your horses.
Don't get too, focused on four dot o. Make sure that you're really, focused on your compliance efforts currently using three dot two dot two dot one. It's not something to lose focus on. It's not changing for a long period of time.
As you remember from those timelines, you got a lot of time to work on this.
As you as you consider, though, of this transition, make sure you're planning to go early.
Working with the QSA if you're especially if you're gonna be using, a customized approach. And I'm not saying validate early. I'm just saying start thinking about it early. Make sure that you understand and get and download the standard when it's available. Start reading it. Start getting prepared. Start thinking about it.
Again, lots of transition time.
So don't forget, three dot two dot one is still the path to compliance. Lauren Holloway provides the following guidance. While PCI DSS four dot o is under development, we encourage all entities to remain diligent, maintain their PCI DSS three dot two dot one security controls.
Not only will this help ensure continued security, but will facilitate a transition to PCI DSS four point o. So thanks, Lauren.
So there we are at the end, and let me just say, kapla, which is Klingon for success.
So, make sure that you hang in there.
Do your best to keep your ears to the ground and listen to find out what's going on with four dot o. Listen for any more announcements from us here at Security Metrics and from the council, and, just hang in there. And thanks for listening.
If you have any questions, please let us know.
For sure, you can email me those questions, or you can contact sales, there at the number below to to get any questions answered.
Been a pleasure to be with you today.
Stay happy.
Stay safe.
Stay compliant.
Thanks a lot.
.svg)
