Securing Coinbase's Edge Payments Infrastructure

good morning I'd like to introduce to the stage now initial char from from coinbase who's gonna talk about what are you talk about how will not steal money or how to steal money maybe from merchants okay cool so my name is let me reset this so hi everyone the title of this talk is protecting the bridge from dollars to Bitcoin securing coin basis edge payments infrastructure the TLDR is how do you threat model a payments network right if you haven't been in the payment space how do you even approach security in the payments world

nope working this way all right please bear with us

there we go cool thank you all right so quickly we'll go over interest I'll just quickly introduce myself what we mean by secure in payments networks we'll talk about privacy and payments and some of the interesting things I've personally seen when dealing with payments networks we'll talk about what a payment network is will actually threat model a couple and then we'll talk about some of the common tools we have in the apps tech world and how we can apply them to payments and then we'll just do a quick recap at the end so my name is initial on the application security team at coinbase I'm one of the maintainer Esther Salas which is our open source

security scanning orchestration tool and then I work on I work with our Fiat payments engineering teams and that's largely what this talk is about is distilling a lot of a lot of interesting events that have happened over the last few years into this talk and some of the interesting things we've seen so what do we mean by secure and payments I think it's important to have a common definition so should a security team care about business logic bugs if they lose money right should these bugs be considered security impacting for example you know is it better to place categories and argue over whether this type of money-losing bug or issue looks like other security bugs right maybe

we're more fully the cross-site scripting or C surf but does that really matter in this case right in the app cycle role the sequel injection or stored our stored XSS or RCE may cause significant damage and may be the focus of most apps like programs but what about in the payments role right here I believe that we should only care about issues to the extent they actually impact a payment system right for example a bug that has money printing implications is much higher severity than just some arbitrary XSS so the two goals that I believe to actually meet a definition of secure in payments the first is minimize money loss right preventing all money loss is actually

impossible and a lot of payment networks and you might be very surprised by this right reducing emergents lost 2-0 it's actually not possible the second goal that was no data loss right we should prevent any personal information from leaking out but you're asking well this is a talk about payments where is PII where is personal data actually involved in this in this network so we'll go over that so kyc AML and privacy so kyc is an acronym know your customer it's typically involves some sort of ID verification and some level understanding of where customer earns their money am L means anti money laundering ml is the goal whereas kyc is a control to enable money anti money laundering

so let's go over a quick example of kind of a very simplified example of what this looks like so Garfield here is trying to deposit some money into their originating bank right you can think of this year as a customer trying to deposit cash in Bank of America Wells Fargo Chase what have you this this amount is the transaction is transferred to the correspondent bank right so this is a middleman Bank and along with that is some identity information about Garfield this is actually transmitted as part of the transaction this also gets sent to the receiving bank so this is the end bank you know the merchant may be using and that often is relayed to

the merchant so even though Garfield believes they're only sending this transaction data they're actually banks are actually implicitly sending a lot more throughout this chain so why does the maybe the correspondent bank get this information what's interesting here is that what's interesting is that the intermediary correspondent banks actually don't perform the KYC checks the ID verification checks that maybe the originating and the receiving banks actually do and why is that well so trampled if Garfield owns a bunch of online gambling sites right these are known to be higher risk businesses and for the context of this slide risk means a higher propensity to you know perform money laundering and then the originating bank starts serving

Garfield's as online gambling businesses then the intermediary Bank actually looks at these risk profiles and may suffer banking relationships with the originating bank right this is too risky for their business to actually work with Garfield's with a type of Garfield's customers so and then so that's that's what the original the correspondent Bank action place then the receiving Bank will also perform these ID verification checks based on some or the KYC checks that be receiving Bank the data it gets what what actual PII is sent this tends to be at a high level some combination of name date of birth physical address physical address scuse me and some unique identifiers like a passport number or driver's license number right it's a

pretty sensitive data so why do banks need to do this well largely for two reasons in the US there's two laws the Bank Secrecy Act of 1970 and the Patriot Act in 2001 and there are other smaller laws that govern this sort of limitation so let's look at quickly how this plays out so there's something called a CTR and a SAR CTR is an abbreviation for a currency and transaction report and a suspicious activity report is known as a SAR so here Garfield wants to submit a 10k you know cash deposit to their bank and what happens here the bank will receive that deposit clicker is broken okay I'll just use them so the bank

receives the 10k they actually file is called a CTR with FinCEN which is a government agency this involves all sorts of details about Garfield that gets filed with the federal regulators so Garfield here is like wait well you know I'm smart enough I'm gonna send a transaction right under this 10k amount I'm gonna send it for nine thousand nine hundred ninety nine dollars so what happens then the bank says well obviously you try to skirt the CTR requirement and actually file a suspicious activity report known as the sorry right what is what does this mean it basically means the bank suspects something is weird in your transaction and they will file this with the federal

government it's actually illegal for the bank to tell you that they filed a SAR against you know your transaction or on your account and it's actually illegal for any of the compliance officers at the at the bank to tell any any other employee at the bank it's actually a criminal penalty under US law what happened the side of the US well there's an agency called the eff ATF the Financial Action Task Force and their job is to come up with recommendations on fighting money laundering and terrorism financing by working with countries to update their laws and regulations so getting blacklisted by the f80 eff has no power and of itself but a lot of governments will use that blacklist and

respect their decisions and will cease international banking operations with that country all right so the eff ATF has lots of power implicit power but no explicit power so that's just like largely how the international world is governed basically the bureaucratic body that sits in France that it's not elected by anybody but back to the privacy section so we were thinking about the scale of privacy what is the most preserving and least preserving privacy type of payments so large international payments are generally the least privacy-preserving and this makes sense because as a country I can regulate you know domestic payments within my country I have I know the laws within my borders right so small domestic payments are generally

the most privacy-preserving but cross-border transactions for example I don't know maybe how good the other country is for their money laundering laws and so that is generally when the most sort of identity information is sent between things so right so a company that operates in this financial world can either add ear to these rules and play by these rules and sort of sacrifice some of these users privacy or you don't get to operate in this world at all and that's sort of the decisions that you have as a financial company so so the best we can is we don't want to prevent data loss but what it means in this case is a lot of these institutions

are going to see data a very sensitive data about a customer and that is considered generally in scope for most payment systems what we don't want to do is have anybody who's not authorized to see this data not being able to see it so there's definitely a gray area that operates it's not there's no total privacy in the current system cool so let's talk about payment networks right this is a way for customers to send you money or for your business to send money to your customers right so you can think of this as credit cards banking AC age transactions right this is nice right your business was like let's take money this is good this is how we run

that's how you get payroll it's all good right but if you're in security you're like okay it's not this simple there's no way it's this simple and you're right right if you're in traditional apps like you would start with some sort of you know fundamental model and rules about how something should work so think of the browser right the browser has the same origin policy it's a fundamental rule about how a lot of controls within the browser work right mixing code and content gives a low rise to a lot of apps like vulnerabilities right and our job security the web browser framework right is fundamentally flawed in certain cases and like we all know that there's nothing we can do

except you know thank our lucky stars that we will have infinite job security because XSS is never a solved problem but back to payments if the goal is to protect money and data in this new system we should at least know and understand the basic operating rules we don't know these will likely make mistakes in our Sussman's and threat modeling or integrations for example not all payment networks finalized when you actually receive your money as a merchant let me say that again there are payment networks that will give you your money and then take it away from you not minutes or hours later but it could be weeks or months later right we should know how customers can

initiate disputes and what rights each side of the transacting party has right for example if a customer claims of the transaction is fraudulent but the business is like no this transaction was not fraudulent the customers lying what rights does a business have in this case right we should know how long can actually take for transactions to finalize right does all the transaction need to be in a terminal State for the state to be finalized and how long does it need to be in that terminal State some of these payment networks are operated by you know the time it was in this terminal state rather than actually being in that state itself cool so let's talk about at a high level two types of

payment networks just too large characteristics that have generally seen the first is pull payments and the second will be pushed payments we'll get into that in a second pull payments are primarily used in the US and most consumers are familiar with this type of system and let's go over an easy example so Garfield uses a card to purchase lasagna by presenting the card to a grocery store right the shop asks fruition from the bank to charge the card the bank sends the money to the store the store sells lasagna to Garfield great there's a grossly simplified if you're in the in the credit card world there are many players but at a high level from a

consumer this is what it looks like the point is that by presenting some credential the shop acts on behalf of the user to pull money out of the users accounts right push and pull actions are based on the perspective of the buyer in their bank account right so here again the merchant is pulling money out of the bank on behalf of the buyer so some examples of this or a u.s. debit and credit cards in the ACH network if you don't know what ACH stands for that's okay if you don't know what it is that's okay you've probably interact with it if you have direct deposit enabled in your own as part of your salary how you take

payroll if you've moved money through your 401 K you've likely operated with the ACH network so in this example let's take a look at exactly what happens cheques are often used the ACH network so in this case Garfield wishes to write a check to the merchant the merchant likely converts this to an e check nowadays this information that gets sent to the bank usually electronically comes back to the merchant and then Garfield guess Rosana so let's think about an attacker right what is the only thing that authenticates this track signature no no not really nobody really checks out these days the routing and account numbers on the bottom of every check is what routes and authenticates the

payment right what's the secret required no secret required now most of you in the apps like business full-time are probably a bit baffled like all you need to drain a person's bank account is a routing an account number yes however most banks have some additional protections to varying degrees of usefulness at the payment Network though the only thing you really need is access to the ACH network and the very public information about a user's routing and account number right as a result there's obvious fraud in the system right this is why banks allow you as a consumer to reverse a transaction for months on end and is a right actually encoded into federal law so let's take a deeper look

at actually how this money moves in this system and then we'll go over the cases like the fraud cases and what merchants can actually do to protect themselves so how does money move between banks this is largely manual right now from small bank to a larger bank to the Federal Reserve and it kind of back down so this is kind of what it looks like Garfield Suns money it's awesome there may be there local credit union goes up to some bigger bank maybe even a bigger bank and then up to the Federal Reserve and then it comes back down the same chain alright this is largely a manual process right even though the sending of

data is automated the processing of transactions is actually very manual ok and how are these transactions processed so they'll actually process in three batches at 6:30 p.m. Eastern Time 12:30 a.m. Eastern Time in 3 a.m. Eastern Time right if you don't make a payment in at this time it gets processed in the next window alright so this is not a real-time payments Network a real-time payment system right so this is why we're using the ACH network in not often can take days for transactions to move through the system so there is something called same-day ACH which I will mention briefly the u.s. supports the ability to processes processing outstanding requests three times a day which I

mentioned earlier instead of once this was implemented back in 2019 right so the improvement to the ACH system since 1970 was I'm sort of one processing time we will have three so the actual file format that gets moved through the system is called nacha it's an XML based file or a fixed slave binary based file depending on which banks and payment process you're dealing with and even though this is electronically submitted there are telltale signs the files are often modified by humans parts of names get deleted address fields are inconsistent for example especially in the binary format where files generally don't even meet spec the way you resolve this is you get a file that doesn't

beaks pet and you call the bank and tell them to please fix their stuff so NACHA is also it's the name of the file format but it's also a group that governs the ACH network they set the rules right they're almost a quasi governmental agency in the same way that the Federal Reserve is a quasi governmental agency my personal favorite drug was nacho is nacho money but bad puns aside we can reasonably see how a system built in the nineteen seventies right this is before email existed right with limited purchase depends limited trusted participants and really without thinking about security and really having sort of any modern technology available this is kind of a reasonable system to come up with right

this is a system built by and for bankers not a system built by technologists so this kind of sound like anything we know about where things are kind of fundamentally flawed oh yeah browsers mixing coding content in HTML so we can't just laugh at banks and say they saw it right we have our own problems too okay we mentioned that there was fraud in the system and how that fraud can be committed this is nothing you should do this this is a purely an exercise a thought exercise so ACH fraud against the consumer right so if we have a rogue merchant what happens in this case Garfield writes their check the attacker may be the malicious

merchant gets a hold of this check right the only thing off entik ating this payment is the routing and account number at this point they mess with the data maybe they change you know a hundred bucks to a thousand bucks they asked the bank in the banks like yeah it seems reasonable you give the money back they give the money to the attacker so that's so what how do you protect yourself well so the one way you can do this is you often will call your bank up and say like hey I didn't authorize this transaction please reverse it okay so that's pretty good like as a consumer even though this can happen and it'll

suck when it happens there's at least a recourse and one that's very friendly to consumers but on the flip side as an absolute person trying to protect merchants what happens in this case where the consumer the end customer is actually committing fraud against the merchant what happens here the attacker writes a check gives it to the merchant that data is sent over to the bank the bank's like you here's your money sounds good shop gives little zhonya see you the to the evil Garfield and then here you go oh the attacker calls up their bank and reverses a transaction right the very same mechanism to prevent fraud against consumers is abused here they call up

the bank say this was a fraudulent transaction the bank reverses the payment pulls the money out of the merchants account but the merchant is left holding the bag right the merchant gave up the goods and lost the money and have nothing to show for it so how do we protect a this fraud rate is this a security concern so one thing to remember if our definition if our definition of secure was lost elimination we would we could not we could not be secure in the system no matter what we did right so this is one of the reasons the original definition was minimized money loss so why even accept ACH right we talked about kind of like this is really messed

up how do we actually why should we actually take it and what this chart represents is that the number of transactions for a business to take hard versus ACH ACH is a much smaller amount versus maybe taking hard payments right this is what you used to pulling out your credit card or debit card right but the amount of money moves through ACH is seven times greater than what moves through cards right so you're not using ACH to buy a cup of coffee you're using ACH to fund your 401 K right so if an investor needs to move a hundred thousand dollars the investor is not using a debit card they're using ACH or maybe it's a wire or something but in

the US for domestic they'll use ACH so we talked about okay so now there's fraud in this system the business requirement is we probably definitely need to take ACH so what can we do as a business to actually protect ourselves so this is one common mitigation that's put in place by a lot of a lot of companies so here the attacker writes a check to the merchant same thing but this time the merchant asks prove that you own this bank account as a way to prove the intention that you're writing that this original transaction was made by you right you can all you cannot later claimed that this fraudulent right so please prove that you've owned this

bank account so the way that happens is the attacker then submits their banking credentials to the merchant they say here is my bank account username and password totp code SMS to FA you've probably seen this the merchant then takes this information and submits it to the bank and like often time will just log in as the user to prove that they have account ownership the banks like yeah this sounds good and then continue with the transaction right money goes to the merchant attacker gets lasagna the attacker has stored it in this case right because we've used this mechanism of having authentication on the payment to make this whole thing work right so most customers so the other alternative

here is maybe you place the the funds on hold for six months and most customers probably won't use your product because they don't want to wait for their funds to arrive in their account for six months so protecting funds here is actually pretty hard if you don't have holds because the business bleeds a lot of money so you can end up with this other system so but if you're in astute listener you may have learned that why did I just submit my banking credentials to this merchant like what the heck and this is why we want to trick other businesses one who transfer risk back to users right give up credentials and by proving account ownership not a great

and I will mention that this is likely against the Terms of Service from most banks when I was just researching most explicitly prohibit users from sharing passwords that isn't their banking site and so and then the claims that federal laws have should protect consumers for unauthorized transactions no longer apply so consumers are stuck in a very weird legal gray area where they're not actually being protected because merchants are doing the best to protect themselves against this fraud in a system that isn't really designated it isn't really designed for the 21st century then you made a spa what about like Oh auth that seems like a reasonable approach to the system and yes you're right you'd be right but

usually the OAuth implementations for most major bangz to only involves pulling down transaction data and it's only supported for major banks right they're not used to actually authorize authenticate transactions or authorize transactions all right and these are the major banks right this is like Citibank JP Morgan and Chase Bank of America or Wells Fargo a capital one if you're down at your local credit union they're likely not supporting OAuth so again this is only for pooling transaction data like with the ACH banking rail you only need a routing and account number to still charge it user at the end of the day right this is just sort of a bandage abandoned band-aid on top of the system but then at the same time

we asked why not just fix the whole thing and I'll say at some point right the incremental improvements to the system is actually very hard to me for example JPMorgan Chase had a bug a few years ago we're signing into your account would give you access to somebody else's like there was no like inheritance there was no like crazy cross-site scripting anything it was just like I signed in I got somebody else's account right TD Bank they had an upgrade that went bad and the site went down for users forever we imagine not being able to access your bank account for over a week and now we want to talk about changing the entire payment network in the US our

operates at billions of dollars of scale so you can imagine why banks are very hesitant to actually change anything here so the technical risk for migration is like a very real thing for banks and then you talk about debit cards u.s. debit card cards like it's basically the same the same fraud vectors a credit card but they the settlement time is actually a lot faster and so they found out but internationally we found a much more reasonable solution and let's go over this other type of payment network it's called a push payment so here push payments Garfield tells the bank they wish to send the merchants some money and then the bank sends the merchants some money very easy

and then the merchant says okay great I'll send some lasagna so you've Garfield this is this is great and some some of the ways that you may be familiar PayPal if you've ever checkout with PayPal this is very much how PayPal works but internationally 3ds cards or international wires or very common payment networks let's look at an interesting example about like thinking about which payment network you are integrating actually matters and like let's let's kind of let start threat modeling some of these in more detail so let's talk about the 3ds card flow and I'm going to simplify this down for the bit and this first example the attacker uses their card at the merchant but then

the merchant says oh no this is a 3ds card please go to the bank to authorize the transaction the bank's like okay you've authorized users authorize the transaction and then no banking credentials submitted to the merchant it's only at the bank and then the money gets sent back to the merchant and then Lasagna sent it's great everything works the attacker restored it right there's this sort of you authenticated the payment as a user it must be used up to you to protect your banks like your banking username and password and to FA codes so let's dive into even more detail it's actually threat model this in like much finer detail about what are all the things I

could potentially go wrong so here at Garfield is the end user we have the merchants with the same icon based before now we have at hot this traffic cop represents a payment processor because the way I often view them is they're just often redirecting the user properly from the merchants to the bank and sending them every which way and it'll you'll see that so here the scar field submits their credit card info to the merchants the merchants like is just a 3ds card that the processor replies yes this is a 3ds card please redirect to your bank and here's the businesses represented by the detour and then they go to their bank and submit their credentials at their bank to

authorize the payment money is sent back this is now we're gonna quickly take a break this is a async flow where the bank process of the transaction submits it to the payment processor and submits it to their merchants and then but the user is still waiting on the banking website so here the bank says please go back to the payment processors to be further redirected okay the car feels like great I'm gonna go to the bank I mean the payment processor the payment rosters like please go back to the merchant merchants that's great then Garfield goes to the merchants and hopefully by this time the money that was originally but represented the money bag already arrives at the merchant and

the merchant pays out for the goods so let's think about all of the things I can go wrong in the system let's use those apps tech skills so what are the things that can go wrong here depends on how how this happens we've seen things where merchants will often use like self submitting forms and just download exercise you know those just download random scripts dynamically that's part of this flow to determine whether a card is through yes or not and it's like why why couldn't just be an API call like much easier but no they want to embed a form onto your site that self submits for like doesn't actually submit anything so that's that's what we've

seen here what about at this step open redirect alright this is basically what this at this payment processor is doing at a high level right we want to make sure we're redirecting the user to their actual bank and not a phishing site that looks like their bank this is pretty important right imagine if you're in this flow and suddenly you're just redirected something that looks exactly like chase calm you'll be pretty pissed what about here see sir how would you get see sir here so what actually happens sometimes the banks don't actually authenticate the user when they're trying to make the transaction they'll just Auto approve it and let it go and it'll say like yep this

transaction and this could be based on some risk thresholds that we like Ellis is under fifty bucks we don't really care just keep going with a transaction to introduce as least as low friction as possible to the users well not in this case all right there's all sorts of fun stuff data quality right we mentioned like a lot of the stuff is like just manually process by humans a lot of times not in the case of 3s cards because they work a lot faster but imagine just for any sort of push payment system what about data handling it's an important xxe right a lot of these problems are just XML based so you actually do have exit C in your system

here then we have D serialization bugs right you just the typical you're reading some file you're creating some objects out of it depending on what framework using Java will likely have some visualization issues here what about at this step but the payment processor this is open redirect and this is what you trust your payment processor like hopefully not to do is to send them at the end of this flow instead of redirecting the user back to the merchant site so think of maybe redirecting the user back to Queen based comm they send the user back to like colon based comm user probably at that point is not thinking about the URL that they're seeing in their browser because

they're just assuming that this does redirect flow is gonna work right so this is an actual really good point of a to try to fish users alright in this last step race conditions what about what is this race condition so this makes sure in this payment system you actually up to make sure that you received the money from the couple of steps earlier before actually issuing the goods right you could assume that oftentimes the user finishes the redirect flow before the act before the money has arrived at the merchants account right so how do you make sure that this doesn't happen right what happens if the user hits cancel at their bank site and the money is actually

never sent back to the merchant but they still complete this redirect flow to get back to the to the merchant site so this is this is often this can be an issue all right one thing to also do for a lot of these redirection checks is you can often check CT logs monitor CT logs for your payment processors and check to make sure there's no weird SSL certs being issued I'm in doing a lot of like detection on behalf of them because often times they don't do it okay so let's think about instead of you know this is the flow this exact same slide from before and instead of thinking about this sort of async processing

that's happening between the bank payment processor in the merchant to receive the money let's think about it slowly through like let's assume the payment is authenticated through URL parameters this is another comment flow we've seen so here basically we assume some URL parameters actually is it's what's sent over through all these redirect URLs that actually tells the merchant that the payment has been completed so there's not it's like a different flavor of the same system so what goes wrong here well how are these parameters are they H Mac are they encrypted you know how good are their keys typically we've seen a lot of what I will call generously crypto creativity at this point and it's actually

something to be very wary of generally most banks have very good like net SEC skills when it comes to like the application security layer like a lot of other API Doc's will often you'll see kind of crazy stuff where you should use you know reverse DNS to authenticate a payment that is coming actually from the bank and you'll see all sorts of interesting stuff that that actually went through an apps like engineer we're probably not a flow okay so let's think about the money bag flow what I will refer to is so sorry this this money bag flow from nothing you are all Paramus with the other one where is just like to and let's assume instead of let's look at

that a sink processing again usually how that happens is through SFTP buckets so that just means the bank sends the payment process or some money however interaction they handle that that's a black box the merchant that gets dumped into some SFTP bucket goes to the merchant merchant usually acts the payment sends it back to the payment processor a payment processor is like great so what actually goes wrong here there's usually race conditions and one of the things that we've seen is payment process as soon as you will read a file the payment processor will delete the file off the SFTP bucket it's a good security practice but what ends up what can happen is if you as the merchants

download the file but don't actually but you have a connection timeout but you've successfully deleted a connection the payment processor doesn't see that you got in the the act back in the HTTP request and they've closed the connection because of the timeout what ends up happening is that they don't delete the file and you'll double process the same transaction because you assume this behavior of the payment processor and deleting the file on the SFTP bucket but general things with the buckets right you expect you know apples for multi-tenant buckets name collisions different duplicate processing right you don't want some new file with newer transactions to override something you haven't read yet just be a denial of

service you expect maybe GPG file encryption IP whitelisting so these are pretty common that we see in most most banks and payment processors will actually will offer this which is a good sign what's also interesting another race condition is sometimes the order of file uploads by the processor actually matters so you would expect that these files would include some sort of header of saying hey this is the failed payments file and this is the successful payments file no that's not the case all the time what ends up happening is that the order of the file matters where the first file that's uploaded is actually the success file and the second file that's uploaded is a failed pilot failed file and then

what happens there is that usually indicates there's somebody at the bank or the payment processor manually uploading these files and when they screw up you have what was a 99% success rate on your payments and a 1 percent failure switch so suddenly you've passed one percent of transactions and you're failing 99 percent because they just switched the two files and there's no other way for you to know and then xxe because most of the stuff is an XML B just because ok so let's talk about there's one last step this actually brings me some hope and it's called reconciliation and this is a process accountants use at most likely at your company to reconcile what their internal

accounting says and and with the payments they've seen flow through the system and then compare those notes against what the processor says they sent right this is a really good process to do because it's like did we lose money in this entire process interacting with these payment networks and what way and they can really help you catch where you're leaking some of this were you leaking a lot of this money but the question is these are accountants accessing this bucket they're not security people so what ends up happening who in your company actually has access to this bucket right are these files encrypted how do you as a customer call up the bank and claim to

say like hey we've had a problem with this bucket with some of the data right how do you make sure that's not a vector of social engineering that somebody can social engineer your company on behalf of the bank to get access to this data so this is a very valuable process for engineering and security to hook into but most most people don't they don't typically look at this ssgt bucket because in most of the integration guides you see this is not really mentioned it's like a footnote and it's usually something the accountants will ask and it'll be in some separate email thread away from security and so what yeah what can happen here talk about

internal controls so it's the same thing when you're when you're dealing with SFTP buckets Ackles GPG encryption IP whitelisting the whole nine yards you know principles of least privilege making sure you're not using shared creds oftentimes a lot of the banks will want to just hey you're the merchant I'm going to give you just blanket merchant creds and not actually give you individual credits for all your users it's what you end up saying right and this is a problem because we thought as security we secured all the SFTP buckets and now there's some other random one lying around so we talked about a lot about two different types of payment networks pull and push we're talking about the

ACH network as an example of the pull based network and we talked about 3ds cards at a very very high level as a push based system let's talk about some of the apps like tools that we can actually apply in the payments role to actually help us make this system better for us as security practitioners so vendor reviews are actually very boring but they're actually super important in this process and something I've taken a lot to heart here so the first thing is like having strong partnerships right so building relationships with important stakeholders it's not just engineering which your procurement and your business operations teams who are writing up these contracts because you want to be

able to tell them there's like an existential risk for integrating with this payment processor before they sign the contract once they sign the contract usually it's so expensive to back out it's not going to happen right so you as a security person if you can loop into that process this is your best chance of actually knowing what are potential problems and informing those partners is right you can inform your engineers of like hey these are the issues and these are the controls we actually need up front before they start any work and this is just like by reading the API Doc's right that's all you really have to do in this process it's actually very

informative and this is a time where you can say like we can't integrate this payment processor because of X or you go to the payment processor and you ask them why are you doing X instead of Y and can you fix it right and this is B and this can actually make your engineers lives easier and prevent them from making mistakes throughout modeling super important I mean that's what we did and most of this presentation rate is at a high level but you know actually building out threat models making timely updates right not just when your systems change but also understanding when the banking api's right we've seen a hesitancy a lot of hesitancy around versioning api's from a

lot of payment processors right they will they will claim to have versions and they'll say it this is API v1 and then we'll introduce breaking changes API v2 and then a payment processor says oh wait but we're gonna make a change to API v1 that isn't breaking and then is breaking so there's a lot of like engineering immaturity a lot of these shops and then automating control stuff saying all right are we you know IP whitelisting or try domain whitelisting for like open redirect is a super easy thing to test for right just like a unit test but you can just test this there and you can automate this control a static analysis or actually

important to lab it was one plus one - well it really depends what if it's one dollar in one cent right units matter here what happens if you're adding a dollar in a euro it's the answer supposed to be in dollars is it supposed to be in euros is it supposed to be some other currency what do you do what about trying to represent a decimal number as a floating point point one and two F this is Python so let's take an example of that quick point one plus point one plus point when decide equal equal to point 3 no it's false right the I Triple E floating point spec is you cannot represent point one exactly like it

isn't possible it's like point one look like five zeros and a bunch of other stuff at the end of it and this is just a base to like approximation of the whole thing and so you end up in this very tricky scenario if you're trying to use decimal places or decimal like points in these operations you will be off and it's generally ok for most companies because you're only going down to like two decimal places but when you start dealing with like crypto and the resolution is up to like you know 18 decimal places or 20 this stuff really matters and you start adding up very quickly and mistakes bug bounties super important right at coinbase we encourage

reports to take advantage of payment systems and our policy for program you know rates these bugs higher right for most companies scary apps like bugs like cross-site scripting maybe a PC era but we want to see cross-site scripting potentially steal money from our users right our highest bounties acquaintance days have all been payments either related to crypto or fiat payment systems right we want to make sure that the severity of this is in line the the in the payouts are in line with the actual report right if there's a potential to steal ten thousand dollars we want to make sure we're paying out more than ten thousand dollars it's actually in the reporters just incentive

to come to us to tell us about a problem and then wingless retros right there could be an instance where hey our engineers just lost five million bucks this week and they will feel bad about it right there's no need for the security team to go yell at them to say you screwed up that doesn't help anybody and it's really take the time to figure out what controls failed not who failed and it's easy this is a general security concern but it's it's very much it comes out a lot more especially in the payment systems and it's very easy just to like blame engineers for screwing something up when it really could be the payment

processor because we've seen all the shenanigans that happened before so here any champions something we've been working on internally at coin base and it's like how and we're probably using it a lot for control steps ting we're trying to work with our engineers to figure out how can we add like automated unit testing and integration testing to actually test for controls within these systems because they have a much better understanding of the tooling and the frameworks that they're using it's not something security could just build on our own and being like here's something you should definitely use it's something that I have ideas about what we should test for and the engineers have a much

better idea of how we can test for it cool so in conclusion to find secure for your company if you're in the payments world right what is secure in your environment because sometimes your engineers and your security team will talk about two different things no your payment networks right you wouldn't start you know browser security without understanding how the browser works right what is the some of the fundamental controls same way for payments you shouldn't really threat model a payment system until you actually understand what the payment network offers and then apply the tools you know we have actually pretty good apps like tools that have been around for you know 20 plus years applying them

to the payments world like it takes some difference there's some differences but I in general they've worked pretty well and I like be a partner to your business at the end of the day right like some networks and processors are better than others and you know being a partner helps to make those like real risks apparent to the rest of the business right if you come back at the end of an integration and say we cannot integrate with this payment processor even though about the flip the switch is not like a reason a laugh at you like it's not gonna happen right but hooking in to when you're doing the vendor procurement is the correct time to actually say no

this vendor is unacceptable and then don't assume anything about payment networks okay it's easy in some of the the data flow diagrams I showed it's like oh this should probably work reasonably well and it's like no they don't every likes to do very creative things which you would think would be the opposite in the financial world and then you know ask a lot of questions right internal partners engineering and even the vendors themselves right a lot of times I get on a call with vendors and I'm like why do you do X and sometimes they don't have a good answer sometimes they have a good answer and sometimes they don't and then they all want to do what is best you know for

your customers and whatnot so sometimes even as a vendor sometimes you just talk about like hey could you do this and so could you could you change this in your API this would make my life easier to make it more secure for your customers and like oh yeah we just never thought about it and usually vendors are very open to to updating their API so thank you thank you to the besides thanks to the claim based payments team and thank you for listening for me ranting a bit up here right thank you very much indeed that was really brilliant thank you for donating your speaker gift to charity the C shirt in were no questions on

slide oh it was obviously pretty transparent so again thank you very much for about brilliant all right yeah way we got a few minutes there any questions that people didn't put on slide out they just want to quickly ask I have one how do you make sure you get early enough in the procurement process that you can actually make a difference by looking on that process that doesn't know what they're doing honestly it was just like find out who was driving that business development within RT within within coinbase and figuring out who was actual point person and being like hey we want to help you do your job better and making sure we're reducing risk to

the business and they're like oh yeah come come come along with all the calls and then you just get more meeting invites Thanks cool