Ashish Rajan: [00:00:00] Start off with the obvious question that when for people don’t know Edwin, who are you? And we can, what should they know about you?

Edwin Kwan: [00:00:10] So my name is Edwin Kwan. I’m actually based in Sydney. So I know you’re in Melbourne, so we’re not too far off. and I look after the application security, at Tyro payments.

So I’ve been doing that for, for a couple of years now. And. I started my journey on this, the security journey for Tyro when we were trying to get our, our food banking license. and I think that was, that was over over five years ago now. So we started that journey. when we started, Tyra was only just doing airport terminals.

So we were doing that for quite a while and we decided to become a food bank and, to get our banking license. And when you do that, you need to do more than just. F Boston section. So card payments transactions, you need to do loans, deposits and everything. So because [00:01:00] of that, we needed to offer more products and we needed to offer more interfaces for our customers to actually, I guess, manage their money.

And we obviously have a large, much greater attack surface area because of that. And hence, we had to. increase our, application security, to be at a level that’s sort of our that’s acceptable or appropriate for their level of risk.

Ashish Rajan: [00:01:25] So what was your path into cyber security?

Edwin Kwan: [00:01:28] So I started off as a software engineer actually, so I started off writing a code.

and it’s quite interesting. So everyone in the team actually has a software engineering or software testing background. So we, I guess everyone started off knowing how the code works and knowing how to test it. And then we transitioned into security. So that’s, that’s the background.

Ashish Rajan: [00:01:50] Would you say, like for some of the student audience that I have, would you favor having a software engineering background is an advantage getting into application security?

Edwin Kwan: [00:01:59] [00:02:00] absolutely. So I definitely would say that having that, because you actually understand that, I appreciate, some of the challenges that,, the developers are facing with application security and why the good things. With having that car background is you’re actually doing security with the developers.

You’re not just, you know, tossing tickets across the fence going, Hey, there’s an issue. It’s an issue. You focus on how to detect the issue, but you also can focus on how to address and fix it and provide some sort of remediation to the issues you have

Ashish Rajan: [00:02:34] discovered. And probably a good segue into, for people who don’t know application security or software security.

Where does that really mean? Like what does that job entail?

Edwin Kwan: [00:02:45] It’s a very interesting question. I actually asked quite a few people what their thoughts are between application security and software security. And I, and I hear so many different answers from that. So it varies from the both one and the same.

and then he also has. [00:03:00] I’ve heard stories where application software security is when you’re building sort of software development life cycle. And once it’s been developed and it’s released you release an app, you don’t really software. Then it becomes the, I guess the upkeep of it as car. and application security and there’s, I heard it another one, let’s say software is what you write application is what you use.

so it varies, but it all comes down ultimately to, for us, our definition of what application security is or what software security is, it’s the whole life cycle of whatever we built, or whatever we integrate with and all the way from. I guess when we start with the ideation of a product all the way until you it’s a life cycle, wake as the commission.

So just making sure that every step of it is looked after the maintainers, the patching, you know, at the end of it, to

Ashish Rajan: [00:03:55] fought for it and how to productive. Would you say there’s another layer to it with the whole, [00:04:00] I guess threat landscape and,, whether, whether you’re releasing product versus apps, is that like, even that subtly has a difference, I wouldn’t say so.

Edwin Kwan: [00:04:10] Not some people would, but I think it’s all it’s, it’s, they’re all just as important. And they all, the salary, I guess, is in the way you think about it, but art in that, I think it’s the same thing. So, you think about really early, you do the trap modeling, you do that in software, you do it in the application side of it, and then when you release it, you still need to make sure you stay on top of the tress.

They are coming in, you know, you’re patching your apps. yeah. Ah, keeping on top with any updates in there. So I would say that it would still be the same group of people managing it the whole way. So I would say someone in they’re both the same

Ashish Rajan: [00:04:51] or they’re both the same. Oh, sweet. Okay. And to your point, I guess probably another way to put this is like, If someone’s from a cloud [00:05:00] infrastructure background and being Clark’s acuity port, because it is so it does, it does the application security side change between say, I’ve got folks in here who have a cloud, that cloud background.

They started off working in engineering space in the cloud, developing infrastructure scored. And just for them, is Apple application security. Does it change between cloud versus on prem? What they were asking before?

Edwin Kwan: [00:05:25] So my view is, if it’s not safe to do it on prem, it’s also not safe to doing a cloud.

So it’s still the same thing. The principles are the same, just because you’re doing on a cloud, doesn’t make anything different.

Ashish Rajan: [00:05:37] Cause what does engineering security culture mean for you?

Edwin Kwan: [00:05:41] So engineering security culture. I guess it’s so let’s look at it. So engineering security and then culture. So treat things now again, what does that mean?

It would be where, and this is my take on it. It would be where security is something that is, part of the engineering [00:06:00] process. It’s not a, it’s not an after Todd is not a bolt on it. Something that you do in there. and it’s something that everyone does. it is just it’s, it’s like, you know, some shops do TDD where they do test driven development, where you write a test before.

You you write the code itself. and you know, when you run, when you try and build something, you make sure that all the tests pass through the test on past you try and fix or address the problem. So. It’s something like that, where security is just, it’s just a fact of that. It’s not something that you negotiate and go, Hey, you know, the security not working, but let’s can we still release it?

It’s just part of the, no, it’s not good enough. It’s not acceptable. It’s not something that we, as an organization are comfortable with. It’s not what we do down here. We there’s any security facts. We were trying to address it before we actually release it. So that’s, that’s my take on it.

Ashish Rajan: [00:06:56] Yep. And to your point, you’re going to a few talks on the topic of [00:07:00] building a security culture as well.

And earlier offline, we were talking about how that’s a, that has a wall. Would you want to share some of that insight on where you saw it then and where you see it progressing the Baldwins, you know?

Edwin Kwan: [00:07:11] Yeah. Yeah. So I think when, when we started our journey, the focus was more, we first want to make sure we get a management buy in on doing security.

and then after that, we focused on everybody who has. A part to play in the development of the software. So we then it’s started off. The first thing that we did was all about awareness. Just understanding why we’re doing this. Why is this important? and we did that, I think, by first doing a scan of all our code, understanding what are the vulnerabilities in our system?

What’s what are some of the floors that we weren’t aware of? And then I did a presentation the year after, and the presentation was. How to hack Tyro. Like it was 2015 when I kind of just showed all the vulnerabilities in that [00:08:00] and how you pivot everything. And it made it more real because what we started off with was when we did training for a buddy, we did the old walks, top 10 training, and everyone’s asked dad or anyone who does security training tend to do that as a basic way.

You kind of learn like, Oh yeah, Injection attack. you know, XSS and the response, we always seem to get quite a bit as, yeah. You know what? Those vulnerabilities are really bad kind of

Ashish Rajan: [00:08:27] stuff.

Edwin Kwan: [00:08:31] So, so, so then we went in and say, Hey, all right, let’s, let’s try and kind of demonstrate why this is important. And we are not the exception. You know, this is the top 10 because it applies to everybody. and we do it too. So, so that would start with that awareness, but just understanding this is important.

it applies to us and then we talk about how do we actually address it? And then once we’ve done the awareness piece, we then went on to tooling to kind of go, how can we identify stuff? [00:09:00] Automatically. Cause now we have, hopefully if awareness you have buy in, in terms of this is important, we need to fix it.

And then we kind of go, what are the issues that we have on there? And the tooling? I had two parts of it was stuff that we ride. And stuff that we use, right. It’s stuff that we would write. We could write some business logic that as vulnerable posts, we need to pick up on those kinds of things. Or we could be using libraries or opensource libraries.

That’s very popular now, that has found the booties in there. So those are the two areas that we kind of focus on, in there. And. we also did like, so Trent modeling and everything help with that. And, and where we’re evolving now too, is we’re using more and more open source. open source allows us to do really quickly, why reinvent the wheel when something really exists for the libraries that you need?

You know, you just have to write the business logic, take that kind of code, to glue all stuff in [00:10:00] together. Do you want to do everything else? You can get someone else to write it. And, and we’ve been looking at a interesting fact thing about 85% of your source code is actually not written by you. It’s written by, opensource developers.

And if you use, No JS or some solid Java script app it’s even greater I’ve. I think someone did some research and it came out about 97% of the code is actually not written value. You use just pulling stuff in, and really 97% of Lord, man,

there’s a lot. And a lot of it is actually stuff that you’re doing and use too, because you pull in some code, you know, a lot of times, how do you decide, or what is the, that, the process for adding.

I guess open source code into your application. What do you get the information from? You probably go to Google, you know, you search, I would try and do this. what has [00:11:00] it, and then. or you might have some experiences on what school. Yeah. So that’s the quite that, especially I people do that. They don’t upgrade the version, here’s the version that’s available and that kind of thing.

and actually interestingly,, we all need to get better at how to copy and paste. You know, it’s not just copy and paste, copy paste, and then read it through it and understand what you should piss thing in there before you actually do it. And what we are seeing is that, so we’re using a lot of open source libraries and those open source libraries also using open source libraries too.

So you might be pulling something in that task that helps you with, I guess, Your logging functionality, you under some blogging. So you just put his library in, but that is also pulling out of business stuff in there. And what I find is that 85% is not written by you. but you’re only using a small subset of that.

The rest of it [00:12:00] is just, it’s runny. And, the interesting bit is. You are probably clueless about it because we have things like, Hey, you know, with tech detective, you’re using this particular library, it has a vulnerability. And the most common response is no, we’re not using that. Like, Oh yeah, you are, you’re not using it directly, but this library you’re using is using it.

and if you think about it, we spend so much time with awareness training, for our developers, you know how to write good code. We don’t spend a lot of time on those open source libraries in there, and it’s not possible, but that’s also a very easy way where vulnerabilities can get it. and it’s also a little bit scary in terms of those vulnerabilities are more publicly disclosed.

So you get a CD that says there’s a vulnerability in this library. and everyone knows about it. There might be some exploits, some proof of [00:13:00] concept written for that. And then they can go, Oh, I’ll just try it and just spray it around the web and see what works. So you’ve got those kinds of things and I know things are, so how secure are the development processes for those developers?

And I’m talking about development processes. I’m not talking about the coding itself, but in terms of keeping your code safe, I’ll give you an example. Like, for most companies you probably have to FAA to actually. go onto your VPN or log into, your source code repository. there, the machinery you use is secure is locked out potentially.

you know, there’s some sort of password policy that you have to change your password. You can use the same password across everything. and a lot of opensource development teams don’t usually have that. a lot of opensource, some of it is sponsored by companies, but a lot of it are people who are [00:14:00] doing it as a hobby, something I didn’t do part time, you know, as part of giving back to the community and contributing that evenings and not doing that.

And some of these applications are actually pretty old too. So they haven’t been. Really looked after, you know, when the developer who started this, did it seven years ago before there was MFA, you know, when passwords are the same password you use for your email password and everything. so that’s, that’s where we’re kind of shifting in terms of security later, but it’s also, there is this whole other team.

That is not your team. That’s contributing to your code, that you are ultimately accountable for there. You’re releasing to your customers there. you need to stay on top of.

Ashish Rajan: [00:14:44] Yup. Yeah. So to your point about having. I guess a for lack of a better word, a random team contributing into your, into your core repository.

The other challenge that I’ve noticed with open source, and I [00:15:00] don’t know if you kind of see this as well is a lot of the open source code is not maintained. Like a lot of times I’ve had conversations that were application batching, and it turns out that the open source library you’re using is three, four years old.

No, one’s maintaining it. Well, you could take on the job of patching it and upgrading the CVE that that’s come out. But do you really want to spend time doing that? Like do you kind of have those kinds of conversations as well?

Edwin Kwan: [00:15:27] Absolutely. You know, that’s, that’s so common. A lot of times what I, what I’ve seen in, and I am guilty of myself of doing that when I was doing actively doing a lot of development is you, you do that copy and paste.

You know, it works. You’re like, yes, it has validated it does what I want to do.

Ashish Rajan: [00:15:46] Yeah, it means sprint over. Thank

Edwin Kwan: [00:15:49] you. Check in commit. Yup. I’ll never look at it again and see you. I’m trying to do something else and it breaks it or something happens. You know, I have to use a new [00:16:00] version of Java or, or, or this new library I’m putting in, or even you

Ashish Rajan: [00:16:03] move on to another company and you just lose the, let someone else worry about that.

Edwin Kwan: [00:16:07] That’s right. So, so that’s, that’s quite common and, the way. That gets brought up sometimes. or for me is when the security person myself comes, see and say, Hey, this library you’re using has a vulnerability. Yeah. It’s 10 years old. if it’s not properly maintained, you’d be like, Oh, what am I going to do?

But if it is maintaining like, Oh, I got 10 years worth of patches to put in there. Yeah. I hope it’s backwards compatible. it probably isn’t. So it’s going to be a lot of work in there, in what, what we’re trying to first, I think there’s two things. The first one is you could have a better selection process.

The selection process is not just. It works. Let’s just go with it. It also depends on the quality of the, the developers who are developing this opensource stuff like with, with NPM [00:17:00] stuff. MPM has grown exponentially in the last few years. you know, the mumbo of libraries going in, I think last year we were seeing about.

I’m going to, no, I did not show any members because you guys make validate me for that, but there’s a lot of first time, contributors who is publishing that there are libraries out there, NPM, and it’s all good, but you want to make sure that. You know, that there is some longevity to the apps that are being released here.

I’m pretty duty myself. I’ve got two open source libraries out there that I haven’t touched in years. hopefully no one’s using them,

Ashish Rajan: [00:17:41] but I guess use it on

Edwin Kwan: [00:17:44] risk. Yeah, that’s right. Don’t blame me for it.

Ashish Rajan: [00:17:48] That’s

Edwin Kwan: [00:17:49] what, what we advocate is pick something that is popular. Use libraries that are very popular because there’s a higher chance that it [00:18:00] is going to be maintained.

And if it’s not, you or someone else as a high chance of someone actually going in there and, contributing to it, and then not thing is really important. Is this going to be more eyes looking at the code, more people evaluating those codes to make sure that if there’s anything malicious in there or any code that has.

Been written in a way where it introduces a vulnerability, it gets picked up. So, so that’s what we do in terms of let’s try and pick something, that is popular. So we’re trying to, for popularity in there. And the next thing that we try to advocate is you should upgrade constantly. You should be constantly updating updates, usually fix bugs.

they also fix security issues and it makes it a lot easier. so we’re trying to advocate that as part of part of just quality. so what I’m trying to push us that, Hey, you know, for development teams, right [00:19:00] now I’ve done a lot, most companies, but security seems to be a, A reaction, right? So something happens, you fix it.

we’ve got all these open source libraries. We’re not going to upgrade until the security and flags it, and then we upgrade it. So it’s the problem is when it’s flat, someone’s really discovered it disclosed it. They’ve obviously reviewed it and then they put the fix out there and then somehow that Intel fits his way into your tooling.

So it’s a little bit of a gap in terms of when that vulnerability is out there, probably a fellow with that. I guess an exploit, opened up a publicly available exploit to when you actually address it. So, what we’re seeing is one to just upgrade constantly. So there’s tools out there. I know, get up with, maybe last year, quite like dependable, whereas the thing that goes in there and whenever it’s a new version, you upgrade automatically.

You see that with mobile phones now where, I know if my iPhone, I used to have to go to the app store and upgrade manually, not tool for [00:20:00] constantly, you know, just constantly get the upgrades. So we’re trying to push for that. Make better choices when you’re selecting. Open source libraries and, spend the tax on that.

You know, you’re just saving so much time really by not having to write the functionality, you need to pay the tax to maintenance techs, to just keep making sure it’s up to date in there. So what we’re advocate is, for, for development teams, you know, every mind set aside one or two days where you just upgraded or you have the thing land, and whenever you make any changes to your code, Spend a, your time to just update everything before you make those changes.

So, that’s what we’re trying to advocate down here.

Ashish Rajan: [00:20:44] Interestingly. I idea I love it to a point about maintenance. It’s a good way to put it. Like, I think it’s great that you, I mean, nothing is free in life, right? As a say, and except for good people and good company, I guess. but, the interesting.

[00:21:00] A part over there for your, from, from yourself is I love the evolution that you kind of spoke about how and where you’re trying to go towards encouraging people to constantly update. I for, I guess, taking a step back and zooming out a bit for people who are starting off today, you spoke about that awareness presentation that you did in your organization.

Now was that I’m assuming that was internally. And, that was that to say the leadership team to get their buying, or was that across the developers so that they understand the importance of what they right. Or I’m keen to know as to where, I guess, at what level does that awareness work? Or that worked for you and the evolution of going into dueling, would you recommend say going for SAS versus the dashboards is the software competition first.

Edwin Kwan: [00:21:51] So with the awareness, it’s both, you need to have support from leadership and then you need to have the support from the people who are actually going to [00:22:00] be the one. securing the applications, with the leadership, but it’s, it’s quite interesting. you need the, there needs to be a reason why we’re doing this.

What was the value of doing security? for us, it’s pretty simple. We’re trying to get a full banking license. You know, there’s a higher bar in terms of what we want to do. To build trust with our customers. so that is, a very compelling reason. different companies have different reasons in there and I guess, you gotta find what works for you, and then once you get that support in there, and maybe I’ll talk about why that supporting important, you have leadership support.

Sure. If you don’t have the leadership support would just say yes to security, but just make sure it doesn’t gain a way of everything else. then you’d be struggling a little bit because, you have. Targets on datelines for a feature release or for, for work to get done. And when those targets are coming close [00:23:00] and they always seem to be always behind schedule, you know, they’re always very optimistic people.

And when. Targets are coming close. You don’t want it to be a situation where security is one of the things that you try and compromise. You kind of go, well, what can we cut? Let’s cut security. If you don’t have buy in from, from the, the leadership team that’s, what’s going to happen. If you do, you can then say that this is the bare minimum.

This is what we would a compromise on. You know, we want ship. products that are broken to our customers. And we also won’t ship anything. That’s below this level of security. This is our risk appetite in there. So that’s why it’s important for that. and it’s also important then for developers themselves to have this awareness.

Because then they would actually want to do it. you might have support from management, but if the developer’s not really interested, then they’re going to do it half heartedly. [00:24:00] They’re going to do the bare minimum. The only going to do what you highlight to them. What we found really interesting was when we did our awareness piece and their presentation, the weeks after that people were coming up to us and going, Hey, I found this too.

I found that too, you know, and I’m like, great, you know, let’s, let’s fix it or how can we prevent this from happening? You know, we’re all about test driven development and what car test can we, can we put in there? what can we put in our libraries? You know, that we’re saying that, Hey, use this library for, for doing this particular functional functionality.

What can we put in there so that. Security is something that is in there. You know, what secure by default is the path of least resistance, you know, just by taking all this Tyrell libraries, you know, you can always for free and it’s secure. And if it’s not, you know, a task would break and you go, Oh yes, I got to do this.

So that’s, that’s dead. So that’s, that is quite important. Yeah, those I think are the two main things in debt. Did I? There’s another [00:25:00] question. I,

Ashish Rajan: [00:25:01] so the followup question was, so once you’ve kind of got the leadership buy in and the developer buy-in, where would you recommend people start? Yeah. What a foundational thing, which is falling or too hard, cause you don’t probably want to recommend something which would be too hard to start off with a climb a mountain the first day.

So what would you recommend people start with from a tooling perspective? Where should they start? I guess.

Edwin Kwan: [00:25:25] So, so my personal view on tooling is so you’ve got the SAS, the DAS, you’ve got all that. I, you want to start with something that doesn’t have a lot of false positives. So I’m going to take the sass out from that initially, because sash required a lot of healing.

I feel that you have with security, you have tree chances. You know, if you have a two in there and it’s always flagging, you know, false positives, people are initially going to be excited from your awareness training. They’re going to look at it and investigate it and they’re going like this [00:26:00] doesn’t make any sense.

and then feed that back to you. and you’re gonna make some changes in our care. You know, it’s working, they’ll trust your studio. Still use it the second time they did a bit, this granted the third time they just going to stop. Writing everything off. It’s like, it’s a false positive. It’s a false positive.

Every issue is like someone crying with. So I would say don’t do those because after a while it doesn’t become, it doesn’t become relevant. It’s not very effective anymore. So security control, unless you can roll something out where you have a high confidence. Yeah, but you, you roll out is actually a security issue.

So, I would say an SCA would be a good one because it was all based on CVS. And so, you would have challenges in terms of our, this voluntary doesn’t apply to us, but there was still a vulnerability in them. So there’s not really a false positive. It’s just that, Hey, we’re using this library, that doesn’t that’s which vulnerably doesn’t apply to the way we’re using our [00:27:00] application.

And that’s fine. So I would start with those easy things in there. I would also start with having, you do some pen testing to figure out what are the common things that we are doing consistently in terms of security vulnerabilities, and then think of what are some of the easy ways I can test for this.

what kind of tooling can I have? you could, maybe it’s almost like stack analysis is like grabbing, right? You’re just grabbing photos kind of stuff. Or you could write unit tests. If, if the languages are quite constantly accompany, you have fixed frameworks, you can actually write something and contribute for those kinds of stuff in there.

Like, Hey, this is the standard set of security stories. I have to think about when you’re developing some stuff, functionality. And by the way, here are some like, some unit tests that you can go into, you know, Buffalo flow is quite common in, in Java libraries, right? Eh, yep. You just, just put this in and then that’s how you test for that.

Or. [00:28:00] Next assignment, use this library, use this test yet. And so those kinds of things are what I would recommend. Something that doesn’t have a lot of false, positive stuff like a desk that requires a whole setup. If you don’t have a staging environment to run it, Might be hard to, so I would say start really small start, really simple, start with things that are definitely security issues for us.

It was pen testing and finding common stuff. And then trying to write test code to identify that and open source libraries because it’s 85% of our code covered right there.

Ashish Rajan: [00:28:34] and it talking about open source is a question from what I guess, more of a statement from Darpan and he’s watching live on LinkedIn.

And his comment is since this is a kind of free it’s, I think it’s important to add licenses to the repo as well. So developers who use it are also encouraged to contribute back with updates, you know, sharing thoughts on that. And, what are your thoughts on licenses?

Edwin Kwan: [00:28:57] Oh, absolutely. it’s not security, but it’s [00:29:00] a very important thing to it’s it’s a legal thing.

So, for us, it’s quite interesting because we have the, the, the tooling that does, I guess that does our security, open source vulnerabilities. Also Tessa licenses are right. And that brings me the really interesting thing to, so, you know, I think that you should have. You should be able to have a list of all the open source dependencies that your company is using half a bill of material, because the worst thing you want is reading on, on Reddit or something about, Hey, you know, ODF found in this particular open source library and you’re asking yourself, do we use this?

if you have. Abuse a material constraint going in and go, yes, we do. Or no, we don’t. Or we’re using this particular versions and it’s quite interesting. So when you start doing that, you might go, Oh gee, I’m using seven different versions of this particular library within my company. Awesome. And your point,

[00:30:00] Ashish Rajan: [00:30:00] sorry, just to add to that.

If water, if you have a large code base, which you’ve been writing and contributing into for years, where does one start, I guess, and that, but yeah, it’s a challenge. Is there any tool that you found it’s easier or is it more that, is there a tool that you’ve tried and. Worked with other work that you can probably share or it’s more spreadsheet and kind of like an asset that people maintain that you’ll see, asset registers that you maintain.

Edwin Kwan: [00:30:30] I don’t recommend those because they can, or they get outdated very, very easily. and it’s, it’s additional work they’re trying to get out. So there are a few ways you could do that, while the ways which we have a few different ways, the main way we do it as we have our main, Repository are our main, open source repository.

I think there’s too many of my trailers. Artifactory and there’s, nexus manager repo manage it. So there’s those two things. [00:31:00] And what we’ve set up is when our build agents are building the pipeline. It doesn’t pool it’s opensource from anywhere else, but from that particular source only. So it has to come through that.

Right, right.

Ashish Rajan: [00:31:14] Yeah. Yeah. Sorry, cut you off. Didn’t want it to cut you off, but I think it’s really interesting that you mentioned about, I guess the. The, the places that can impact. But, I wanted to switch gears a bit as well because, I think the territory that we’re going into with our poly calling and, or the name is DevSecOps, what is the like ops?

Edwin Kwan: [00:31:34] So DevSecOps is a mindset, right? I feel like it’s a progression, right? So it started off with dev ops and in my mind, DevOps started when developers are going, Hey, you know, The operations team are fairly slow and try and rule out the changes that we want, you know? and, and that was because there was two different mindset developers, we’re all motivated by getting features out the door, you know?

Right. [00:32:00] Quick, let’s get out there. Let’s innovate. Let’s be fast. Operations are responsible for the smooth running of the application itself. You know, they want, they don’t want a lot of change. They wants the brewery, you know, any change, anything is broken they’re on the hook for it. for that. So there was that friction where Def were going, Hey, let’s just go fast.

And then aspirin. Wait a minute. If you’re tired about this, have you thought about dad? What is the planning in cases, firms over at 2:00 AM in the morning? What do we do? so that’s where that happens. And. Then they decided, for us it was more about it. And the idea of you’re good at your writing. So it’s no longer a thing where Def looks after building it and then turn it over to ops who looks after it for the rest of his life.

So, you know, just constantly just giving you more and more stuff it’s now you’re building it in. You’re also on call. You’re the ones who’s maintaining it. And it kind of makes sense because you understand it best. [00:33:00] What’s interesting. I remember seeing was, when you have, an issue at 2:00 AM in the morning, the operations guy would be let’s try and do the least amount changes.

Cause I’m quite tired. What can we do just to fix it? Whereas the Def would go into the code and Google, what code changes can I make to fix this? You know, let’s try and change everything. But, but the idea of the thing, that’s the idea of how dev ops came about. And then DevSecOps is something that people put in there in terms of, Hey security, shouldn’t be something that you do at the end.

It’s something that it’s a mindset that you want to do in that. so I think that word came in there just to hide the fact that security is just as important. You know, it’s something that you shouldn’t be. Thinking about at the end, it should be something that’s part of, I guess, accountable. It should be in that same group of people too, for DevSecOps.

Now the book that, that, that, that, failures in DevSecOps. Yeah, that was actually quite interesting book. I think it was two years ago. [00:34:00] And that is a collection of stories that a bunch of. Of of, of folks that are friends of mine to get it and wrote that end as it came up, because we were actually speaking at a conference in RSA Singapore three years ago.

And we’re having a, I guess after conference strings and we’re talking about it. You know, try and just, I guess, pick each other’s brains. And then, so we’re trying to do this. and the good thing about networking is trying to learn about all the mistakes people make so that when you’re trying to do something, you won’t go down the same path.

So they’ll be saying things I’m trying to write a SAS. What should I do? And for, since I got don’t do this, don’t do that. And we then, for some reason, progressed to stories and those of Midas dusters wasting yours. And what have you got. And then I think we walked away going, wow, you know, this, this is actually really interesting.

You know, we do a lot of times on, on at conferences or meetups or even just, on the internet. We always talk [00:35:00] about what went well, you know, this is how we do it. And we don’t always talk about. What went wrong, what the failures are, which, in my mind are just as important because that tells you what you should be avoiding or, or some of the pitfalls that, you know, don’t go down that path.

So, hence we wrote this book about the things that we try to do, that we thought was going to be really good, but they were a fail. So the books called Epic failures in DevSecOps. So, so my mine was about Trent modeling. So we, we try to raw trap modeling to the whole company. This was the, Oh, initially, the phases that we had.

So we we’ve got the awareness and we’ve got the tooling and we’re like, alright, we’re gonna do trap modeling. We can try to understand this. Went online, look at this Microsoft chat modeling. They got this track process, but yeah, pretty dreadful. It was a way of thinking about tracks. And we were like, all right, you know, this is created by Microsoft seems to be, you know, [00:36:00] we try and put it out there to the developers.

And I think we didn’t approach it correctly. just people just hated it. It was just too, it was too long. The process was too rigid. It wasn’t something that was very, very enjoyable. And it was because we usually had a microservices architecture. So it’s so many microservices and people that you already see how they made sense for, the trembling approach that we were trying to put in there.

So we did a lot of staff, in there. We tried to force people to do it that went so far. then we ran, well, people were, were losing support. People are just going to security shit and start looking at us and going, this is terrible. So we started shifting away a little bit in terms of, going on a path of.

Of test code. You know, we have code that actually verify certain thing and that worked for us then because [00:37:00] we had very standard, standardized ways of doing things, you know, one way. Of doing logging. We have one way of connecting to a database, you know, everybody’s just the same kind of database, software and same libraries use, with the same way of doing inter system off, you know, everyone is the same.

So we then had all these libraries in there and the tread modeling was all essentially, like a big unit test that just verified all the controls in there. So that was what, what worked for us back then? yeah. I’m going to switch gears. So towards the end, I kind of asked these fun questions, which are nontechnical, just to know you as a person to let the audience get to know you as a person as well.

Ashish Rajan: [00:37:41] The three questions for us, what do you spend most time on when you’re not working on application security or, doing your regular full time job? I guess

Edwin Kwan: [00:37:50] so, really interesting is I still spend some time with security, so I’ve. I’ve been installing, lots of security monitoring tools in my home [00:38:00] network.

You know, I’ve just got a, a pie hole set up, which blocks like ads going out. I’ve got a Grafana server, running to tell me, you know, when the doors get open. Whoa. Yeah. So I’ve been, been, dabbling with Dell a little bit currently installing security onion, just to see what’s happening. And a lot of it is.

You would think it’s paranoia. It’s not really, it’s just, you know, just having hands on the toes, you know, just having some fun, letting apart certain things and just tinkering and just like being

Ashish Rajan: [00:38:34] paranoid. I think it’s just awareness, right? I mean, would you not want to know what’s going out of your house, I guess in terms of network activity, it was just something that you can’t feel usually.

I mean, that’s how I see it. So I I’m totally with you. I was going to ask you for like ambition maybe after the interview, then what do you that can, where the experience has been sounds like we need to have another talk about that later on. The second question is what is something that you’re proud of, but it’s not on your social media.

[00:39:00] Edwin Kwan: [00:39:00] Ooh, something that I’m proud of. that is not on my social media. That’s really interesting. it is a tough one because there’s, I’m trying to think of what, what, what would it be. Well, I could share, I guess the main thing I’m, I’m pretty proud of it. so I’ve, I am an avid scuba diver, so I don’t ask about diving.

I’m actually a dive instructor, so I teach diving too. Well, I’ve been doing that for, so I’ve been teaching for about 12 years now, so I’m pretty proud of

Ashish Rajan: [00:39:33] that

Edwin Kwan: [00:39:35] one. I’m really proud of that are what I’m really, what I really like about it is when you do a lot of scuba diving after a while, and almost a diving is in Sydney around here.

So after a while he took it for granted, you’re going like, Oh, it’s just a shock. It’s just boring. And teaching diving is. Quite rewarding because you take students who’ve, who’ve never been in the water first time and they’re looking at it and going, Oh my God, that’s amazing. And it makes you [00:40:00] appreciate what you have in your backyard.

Like you don’t have to go to Cannes or way timing. So, so that’s what I’m, I’m, I’m really, what I really enjoy

Ashish Rajan: [00:40:11] is that a particular sport for scuba diving that you really like in Sydney, That’d be people from city. You can check out on anyone who’s coming to see me. You can check out.

Edwin Kwan: [00:40:19] There are pretty good spots.

I’ve probably not really paid anyone in particular. there is one near, near canal. It’s called the leap. it’s like a dream adrift doctor. You’ve got to jump in at a correct. Tight. Otherwise you might go out into the ocean running and back to shore, so, Oh shit.

Ashish Rajan: [00:40:40] Oh, Oh right. Okay. One of those advanced ones, I guess.

Edwin Kwan: [00:40:46] You could say, so it just takes a bit of planning before you get in the water.

Ashish Rajan: [00:40:50] Yep. I only had a couple of experiences with scuba diving, but it definitely is quite, it’s such a different world are down there. It’s not even funny. the final [00:41:00] question that I have is what’s your favorite cuisine or restaurant that you can share with people?

Edwin Kwan: [00:41:05] I actually like Asian food. So this is a place near my work, has great luck to us. And that’s where I go when it’s on a cold rainy day or it’s raining right now. And it’s nice and warm. So I have, I’d like, I like Asian cuisine. Malaysian food is pretty good.

Ashish Rajan: [00:41:21] Oh yeah.

Edwin Kwan: [00:41:22] So yeah. Luck luck sells on a hot day on a, on a cold day.

It’s yeah. Yeah,

Ashish Rajan: [00:41:27] I’m a big Popovich fan as well. It’s that? I think it’s amazing how they’ve been able to blend different Asian food cuisines. I think Malaysian food definitely has that like has like combination of different cultural food in one sport, which is just amazing. Like in the same restaurant I’ve had Indian Singaporean and like there’s different variations of it.

I don’t know if that, if that’s how you see Malaysian food as well, but I love that about Malaysian food.

Edwin Kwan: [00:41:53] Yeah. Same here.

Ashish Rajan: [00:41:54] Yeah, thank you so much for your time, Edwin. I really appreciate it. It was really entertaining [00:42:00] at the same time as a, it was educational as well. Thank you so much for taking the time out for this man.

Really appreciate it.

Edwin Kwan: [00:42:06] Thank you. And thanks for having me. I really enjoyed being on here.