AppSec Builders

Developers vs. Security Training with Jim Manico

Jul 9, 202100:39:03Tap to summarize

In this episode of AppSec Builders, Jb is joined by security professional Jim Manico, founder of Manicode Security to discuss Application Security, Developers, and why they should be trained to build Secure Applications .About Jim:Linkedin: https://www.linkedin.com/in/jmanicoTwitter: https://twitter.com/manicodeJim Manico is the founder of Manicode Security where he trains software developers on secure coding and security engineering. He is also the co-founder of the LocoMoco Security Conference and is an investor/advisor for Nucleus Security, BitDiscovery, Secure Circle and Inspectiv. Jim is a frequent speaker on secure software practices and is a member of the JavaOne rockstar speaker community. He is the author of "Iron-Clad Java: Building Secure Web Applications”  from McGraw-Hill.TranscriptIntro / Outro: [00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern AppSec hosted by JB Aviat.JB Aviat: [00:00:14] Welcome to this episode of AppSec Builders I am JB Aviat and I am honored to welcome Jim Manico, who, on top of being a famous, opinionated security professional, is also the founder of Many Good Security, where she trains software developers in secure coding and security Engineering he is also an investor advisor for many companies, frequent speaker on secure coding practices and a book writer with Ironclad Java Building Secure Web Applications. Jim, why don't you introduce yourself as well?Jim Manico: [00:00:50] Jean-baptiste is a pleasure to be on your podcast and your show. And like you said, I'm an opinionated application security professional. I just hope that my opinions are helpful to you and your audience.JB Aviat: [00:01:04] Opinions are always helpful, especially when they are held by smart people. So, yes, definitely. And I'm looking forward to have you sharing a bit more about that with our listeners. So, Jim, thanks a lot for joining us today. So when we are familiar with your work, we can notice that your primary focus is developers. So you train them, you write books to educate them. You contribute to a lot of OWASP resources around education. Why that focus centered on the developers?Jim Manico: [00:01:40] I believe that the application security industry traditionally has primarily been about security testing and dev ops and all these different pieces that are about assessment of the security of an application. And I do not believe that you can achieve security through testing. I believe that the only way to truly do application security is to get developers to build secure software and to utilize tools and techniques and processes that will help developers, author, secure software. And I believe that our industry places very little focus on that important specialty because it's hard to sell an idea. The idea that you must change your process, you must change your engineering capabilities and similar. It's not something that sells in the marketplace. It's education, which is not a very big part of our industry. So that's why I focus on that, because it's my specialty and it's also my belief. That's how you really do application security is to enable developers capabilities around security in some way.JB Aviat: [00:02:54] And a so you've been doing that for a while. What are the big changes that you have witnessed over the past year?Jim Manico: [00:03:01] I think the acceleration of dev ops is very interesting. Now, Dev Ops has been around for 20 years. This is about automation around the building, testing, deploying in other aspects of the SDLC. And we were doing that in the late 90s through a lot of custom scripts and similar. And I think that today there's extremely modern tool sets like Jenkins', GitHub actions and similar, where I can build a significant security centric dev ops pipeline in a really short amount of time now, especially if I'm using GitHub actions. Click, click, click. And I got dependable that I got static analysis and some grep. I got dynamic testing and similar testing tools really rapidly in terms of setup. And I believe in a few years that when we're using GitHub in similar repositories, advanced security testing that we see today will be natural and automatic in just a few years. Other trends that I have seen are for more intellectual is the migration away from traditional session management and the movement of stateless session management using JSON Web tokens and the OS two and the open IDE Connect protocols and other JSON Web tokens centric standards. This is a very big departure and change around how secure Web and API applications are built. I also see a lot of new changes in HTP response headers, content security policy, the different response headers to delete site data at logout time, ways I can configure referrer policy or very granular now the advancement of cross origin, resource sharing and the capabilities being available in most every browser. I think that all those response headers have changed dramatically in just the last couple of years to give developers more security capability in modern browsers.JB Aviat: [00:05:07] I definitely agree that don't get me started on JSON Web tokens, but. She already did, and that's a huge fan of the and we took in, because I think that's an interesting evolution in the world of security. It's a bit complex to configure. Right. There are several things you don't want to forget. And to me, that's a tool that has very interesting properties. But that is a bit hard to give, as is to developers like these specifically need the training and education in order not to misuse it. Right.Jim Manico: [00:05:38] I've got to be honest with you. Using JSON Web tokens is radically more difficult. You now have key management secrets, management, the implementation of log out and idle time out, which was easy. In Session management is a challenge with Jason Web tokens that you can certainly achieve more scale. And if you're using micro services, you kind of need to use adjacent web token because it's difficult in a scalable, performance friendly way to tie sessions together among many small services. So, Jean-Baptiste, I really like the back and front end pattern, the PDF pattern where I have more of a traditional session between my JavaScript client or Web client and the main API that serves as a reverse proxy to a fleet of micro services that is back in my private infrastructure. So that way I can still benefit from the statelessness of micro services and performance, but still have a traditional session between the JavaScript client and either a gateway or a reverse proxy API. So all the mess of JSON, Web tokens and micro services are behind the scenes. So I actually agree with you. I really don't like JSON Web tokens when you push them to the client all the way. I try to avoid high powered access tokens and Jason Web tokens from being in a client in particular. I mean, like a browser web client, because there's no good place to store sensitive data long term in a Web client. It's just not mature enough for that yet. So if you're going to use JS on Web tokens or if you're forced to because of the use of micro services, again, the pattern is called the B F f the back and front end pattern, which basically takes the mess of micro services and Jason Web tokens and pushes it back into your private infrastructure alignedJB Aviat: [00:07:37] With your line. Yes. Things. So I think that's a very interesting time to be in security today because. Yes. Of things evolving. You mentioned headers, Clinton's security policy. So, yes, we have a lot of new tools that are evolving and changing the security capabilities that are into the hands of the developers. So that's a necessary step in the journey towards being more secure. There is no question about that, though. Those tools and those security primitives are still extremely complex to implement. If you take a look at the latest security headers that are centered around the Specter meltdown, protections like the complexity of those is really insane. And I feel either we need weeks of training for the developers that will have to use that properly. And Fulu is the mess of like its original house brothers, etc. though we need something in between, like a layer that will automatically configure the application. And I think this is where there is a builder between what you can teach the developers. And no one has infinite time to teach developers and what the tools should be responsible of. And so you said one very interesting thing in your introduction, Jim, is that you teach the developers to use the right tools. And I think that's that's a big part of the business, is to help them find the right tools.Jim Manico: [00:09:07] So let's talk about Spectre and meltdown briefly. Spectre and meltdown is the ability to read data out of a CPU cache. Right. And in my world, this is mostly a problem with the Web browser. Like I'm worried about Chrome and Firefox and similar having an attack with malicious JavaScript cross site scripting primarily, or a malicious third party library that allows malicious JavaScript to read data out of a CPU cache. And we saw a demonstration from Google who provided a JavaScript demo around exactly how this could be done. Now, how is this problem solved? The problem is usually not solved by a web developer building a website or an API. The problem is solved by a browser developer and I do not teach browser develope...

Transcribe →

Are Cloud Vendors also Security Vendors? with Sarah Young

May 14, 202100:34:00Tap to summarize

In this episode of AppSec Builders, Jb is joined by Security Architect, Sarah Young, to discuss Cloud Security, its evolution, and its increased presence within Cloud Vendor solutions and platforms.About Sarah:Linkedin: https://www.linkedin.com/in/sarahyo16/Twitter: https://twitter.com/_sarahyoSarah Young is a security architect based in Melbourne, Australia who has previously worked in New Zealand and Europe and has a wealth of experience in technology working across a range of industry sectors. With a background in network and infrastructure engineering, Sarah brings deep technical knowledge to her work. She also has a penchant for cloud native technologies.Sarah is an experienced public speaker and has presented on a range of IT security and technology topics at industry events both nationally and internationally (BSides Las Vegas, The Diana Initiative, Kiwicon, PyCon AU, Container Camp AU/London, BSides Ottawa, BSides Perth, DevSecCon Boston, CHCon, KubeCon, BSides San Francisco). She is an active supporter of both local and international security and cloud native communities. Resources:Cloud Native Computing FoundationTranscript[00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern AppSec hosted by Jb Aviat.Jb Aviat: [00:00:14] Welcome to this episode of AppSec Builders, I'm Jb Aviat and today I'm thankful to welcome Sarah Young, who is a senior program manager in Azure security. Sarah, you're very prolific in this security space which conferences, the Azure security podcast your also CNCF - Cloud Native Computing Foundation Ambassador. Sarah, I'd love to hear more about this.Sarah Young: [00:00:38] Thanks! And thank you for having me. Yeah! So many things I could say. So, yeah, I worked for Microsoft. So of course, every day I work with Azure and do Azure security as one would expect. But I've been working in security for oh. Like specifically focusing on security for the last eight or nine years now. Before I joined Microsoft, I worked with other clouds and so I got a fair bit of experience there. But with regards to CNCF I am, as you said, an ambassador and although I'm certainly not a developer, I certainly find the security aspect of cloud native stuff really, really interesting. And that's what I enjoy talking to people about.Jb Aviat: [00:01:20] Alright. And so one thing you seem to be prolific about is Kubernetes and Kubernetes is definitely something that has gone through an amazing popularity over the past years and also got a lot of security exposure because it's notoriously a complex and difficult to use in the secure way. Do you have any specific thought about that?Sarah Young: [00:01:42] Yeah, the of specifics we could go into here and I guess watching Kubernetes over the past two or three years has been really interesting because obviously there are new releases and every time there's a new release, there are updates and improvements made to it. Obviously, I focused more on that for me. I'm more interested in the security side of it. But it's really interesting if you go from the early days of Kubernetes through to now, how much it's improved. I mean, what are we on now? I think we're on twenty, twenty one or something like that. I forget the exact version. We're up to for releases at the moment. But if you go back to the early days or two, three years ago, there was some major, major security holes and Kubernetes. So there were things I mean, it didn't support RBAC or role based access control. So if you don't have roads, access control, you literally can't give people permissions, like everyone just has everything, which is a security person's nightmare. So it's been really good to actually see how it's developed over the years and how the community have addressed those things.Sarah Young: [00:02:46] Now, I'm not saying it's perfect yet, because to be honest with you, let's be honest, like no software, no hardware, nothing is perfect security wise. And and that's what partly why I have a job, because whenever people create things, there will be security holes or things that it doesn't do ideally. So it's been really good to see how the community has really focused in on security more the last few years, because I think in this super, super early days, Kubernetes was just being built more from a traditional developer perspective. People were thinking about the features and what it could do and not the potential security gap. But now that's changed a lot. There are some great people out there in the community who are doing security work. They now have, because this week, while the week we're recording this, it is KubeCon EU and KubeCon's now got Cloud Native Security Day. And there's also the special interest group in the community for security. So certainly it's been really great to see how that has grown over the past few years because they'll always be things to address for sure.Jb Aviat: [00:03:50] Of course. Of course. And so that is very interesting. And how even that's community driven project. How is the decision to prioritize security features made over the decision to prioritize the thousands of the features that are in the.Sarah Young: [00:04:08] I wouldn't say it's an interesting question, because this comes back to a thing that the endless battle that security professionals have is the when you are developing any kind of system, not just Kubernetes, any kind of system or product in I.T., the main priority, of course, is to have the functionality that it needs to do to fulfill whatever business need or functional need that the product needs to do. And security is great, but you can't have security will never win out as a priority over costs, delivery date, and functionality. And there are some there are different trains of thought on this. But I think having worked in delivery as well before, I kind of became more purely focused on security role. When you're trying to deliver something and get something running, you know, you're building a new application, you're building a new micro service, whatever. You know, if you've got a deadline and a budget, you have to meet that because probably your business is paying for it, your project is paying for it, whatever. Security is great. And I think that most devs and security people want to do it. But security is never going to win out over those competing priorities, but pretty much never. Now, I'm sure there might be some better examples out there.Sarah Young: [00:05:27] So really, what we've needed to do in security is security need to be made easier, because if it's not made easier to do and ideally in built into a product, it won't win out over other priorities. And there are some security people who just want to try and really push people saying, no, you know, you've just got to prioritize it. But the fact is that it won't win out over delivering budget and things like that. So we have to make security easier and more straightforward. And I think it's great that the community has embraced. And that's why let's take Kubernetes. It's got now a lot more inbuilt security features. They rather than you having to use a third party Add-On to integrate, say, role based access control or key storage or whatever, like a lot of those things have been fixed. So when you start up the product, that security issue is already largely taken care of. All you do a tiny bit of configuration. And so it's great that the community have actually addressed that because yeah as I said, I wouldn't say I think there's been more focus on it because, of course, you know, if you have a security breach or something is known as being insecure, like a piece of software, people don't want to use it.Sarah Young: [00:06:41] But as I said, as a business, there are other priorities. But another great thing an old boss of mine told me a few jobs ago was and I really, really like this, we're not competitors when it comes to security. Now, what that means, because I was working for a financial services organization at the time, is that when we talk about security, right. If there's a vulnerability in something that's widely used, it's worth fixing. And even if you're fixing it for your company and it helps your competitor, then that's OK. Because at the end of the day, if you look at the cost to security breaches, although, say, I'd say you're an organization in your your main competitor gets owned and like you might be like, yeah, that's amazing. But it's not really because at the end of the day, we all lose out on security breaches always at the end of the day. So it's within everyone's interest to work together to make the overall environment more secure. And of course, there are different ways of doing that. But I really strongly believe in that phrase that my old boss taught me, which was, yeah, we're not competitors when it comes to security. And so we should help each other out.Jb Aviat: [00:07:55] Yeah, that's an interesting point of view. And that's great that each time there is breach the overall trust is touched and impacted. And so that can indeed be hurtful for the overall space or industry. Interesting, yes, and to ...

Transcribe →

Shift Everywhere with John Steven

Feb 10, 202100:39:06Tap to summarize

In this episode of AppSec Builders, Jb is joined by security expert, John Steven, to discuss his BSIMM study findings, the fundamental shifts in AppSec, software-defined security governance, and much more.About John:Linkedin: https://www.linkedin.com/in/m1splacedsoul/Twitter: https://twitter.com/m1splacedsoulThrough his firm Aedify, John advises innovative security product firms as well as maturing security initiatives. John leads one such firm, ZeroNorth, as CTO. For two decades, John led technical direction at Cigital, where he rose to the position of co-CTO. He founded spin-off Codiscope as CTO in 2015. When both Cigital and Codiscope were acquired by Synopsys in 2016, John transitioned to the role of Senior Director of Security Technology and Applied Research. His expertise runs the gamut of software security—from managing security initiatives, to cloud security, to threat modeling and security architecture, to static analysis, as well as risk-based security orchestration and testing. John is keenly interested in software-defined security governance at the cadence of modern development. As a trusted adviser to security executives, he uses his unparalleled experience to build, measure, and mature security programs. He co-authors the BSIMM study and serves as co-editor of the Building Security In department of IEEE Security & Privacy magazine. John is regularly invited to speak and keynote.Resources:Latest BSIMMAedify SecurityConcourse LabsTranscript[00:00:02] Welcome to AppSec Builders, the podcast for practitioners building modern AppSec hosted by JB Aviat.Jb Aviat: [00:00:14] So welcome to this episode of AppSec Builders. Today I'm proud to interview John Stevens. So, John is the founding principle at Aedify where he advises product security firms. John, before that, you led ZeroNorth as a CTO and before that you were leading as co-CTO at the Cigital firm. Welcome, John.John Steven: [00:00:36] Hello, how are you? Thanks for having me.Jb Aviat: [00:00:38] I'm great, thanks for joining. So John, another thing that you've done is that you co-authored BSIMM, so could you let us know what it is and how it can be a useful tool to AppSec builders?John Steven: [00:00:50] Yeah, it's worth clarifying because it's frequently misunderstood. The BSIMM is the building security in maturity model observational study. We went out and over a period of 11 years we've studied about two hundred and over two hundred firms and asked the question, what do you actually do to build your security initiative and to secure your software? And it doesn't prescribe what to do, but you can use it to look at what firms that are within your vertical or that look similar to you in terms of maturity, are doing with their time and money, and decide whether or not you want to replicate those behaviours or cut your own.Jb Aviat: [00:01:29] So you are interviewing like CISO application security practitioners, developers like every actor of the security game.John Steven: [00:01:38] Yes. Historically, the list has looked like what you described. What was interesting to us about the last two years of this study is that when we began talking with the CISO, they'd say, oh, you need to talk to the VP of Cloud on this, or actually you need to talk to the SREs and to to delivery or to the VP of engineering. The people we had to talk to fundamentally changed over the last two years. And that was a key finding that we we wrote about this year, that the people doing the work of security were shifting from the security group to the engineering, digital transformation and cloud groups.John Steven: [00:02:20] And that's a big deal, right, because there's been these phrases that we've held dear for 10 years or more. You know, building security in is something that we've said for two decades. Me and a colleague argue as to who said shift left first and we've ended to like November of 2001 when we first said that. It was a long time ago. The other thing we say is that security is everybody's responsibility. Every developer, every engineer, every operator needs to think about it. And we've been harping on those things forever. And what we see is now that engineers, now that SREs, now that operators are taking a really first class citizen role in security, people are taking that 'security is everybody's responsibility' to heart. And in fact, who makes up a security initiative has now changed. And that's a really big deal.Jb Aviat: [00:03:08] Yes, it is. And so a trend that we have seen over the past two years is like QA testing moved from dedicated teams towards the hands of developers and they are now writing their own data and then monitoring their own deploy, running back if necessary. And so what you describe about security is following the same trend, right? So the teams are now starting to own security by themselves.John Steven: [00:03:35] Yeah, and we see what we call engineering-led security initiatives, where engineers are not only acting as security champions and participants in a program, but the owners of practice areas and the drivers of the program. So it's not uncommon in some organisations, particularly ISPs, that are more mature, for them to have a Product Security Lead or a Chief Architect who has full purview and responsibility for security and for those people to do the things that you'd expect the security group to do prior. Pick defect discovery tools, tune those tools and drive to a secure coding standard, you know, generate and administer a training program associated with those standards and those tools, you know, and build security blueprints and so on and so forth.Jb Aviat: [00:04:22] And so you mentioned shift left. So now what I understand is that you are not like advertising shift left anymore. So, due to this change in the industry, now that security is done to be done by people that are actually conceiving and building the things. John Steven: [00:04:41] With the benefit of time, anything, anything will look wrong, I suppose. So, you know, when we talked about shift left, we were thinking about all of those organisations that use spiral or iterative development or even worse, waterfall. And, you know, we would talk about, look, you know, we can pentest your software, you can apply testing to your software. But wouldn't it be better if you moved earlier in the lifecycle and found those bugs as you were developing them so that they were easier to remediate? And that was the basis of shift left and everybody cited the rational study and it's cheaper to to fix things earlier and yada, yada. You can see why that's a valuable precept. But think about how orchestration platforms and how software delivery has changed over the last five to seven years. We're using Kubernetes you know we've changed the way virtualization has happened. We're layering on top of Kuberntes things like Istio. More and more of the way we deliver software is becoming code, and the whole infrastructure is code movement and the whole delivery and pipeline orchestration movements. What that means is that more and more of the stovepipes between build, test, deliver and operate are being broken down, so that a DevOps engineer can shepherd a greater percentage of the software lifecycle in self-service mode. I don't have to hand something over a wall to you. I can walk it further down the lifecycle pipeline myself. And even the the bridge between Dev and prod is becoming a softer wall than it has historically been.John Steven: [00:06:26] Cloud, open-source, all of these are self-service technology stacks that allow you, again, further control over a larger percentage of the lifecycle. And so what that means is that code is creeping right in the lifecycle. When you use Kubernetes Istio configuration files, when you use infrastructure-as-code, cloud service provider configuration, what you're doing is you're driving that code right in the life cycle and saying more and more of the way I build, package, deliver and operate is going to be software defined. So more accurate than shift left is maybe shift to where the code is. And what we're seeing is that the code is shifting right. So your know my keynote of the BSIMM conference two years ago was shift right to do security everywhere. And it was extremely aggravating to the attendees because after two decades of moving to the left and trying to get closer to design and requirements, I mean, Laurie Williams out of North Carolina has published a study that says that as much as 10, 11 percent of your code may be infrastructure-as-code and that 30 percent of the churn, month to month in your code bases, is that code. So there's data based evidence that says that that code is moving right.John Steven: [00:07:42] And so we must move right with it if we want to get earlier. And so this is really never REST. Your security initiative needs to follow the tr...

Transcribe →

Serverless Security with Erica Windisch

Jan 20, 202100:37:49Tap to summarize

In this episode of AppSec Builders, I'm joined by New Relic Principal Engineer and AWS Serverless Hero, Erica Windisch. Erica has decades of experience building developer and operational tooling to serverless applications. We discuss all things serverless including why you should care about serverless security, designing app security when migrating to a serverless environment, how to scale your app security with serverless and much more.About Erica:Erica is a Principal Engineer at New Relic and previously a founder at IO pipe. Erica has extensive experience in building developer and operational tooling to serverless applications. Erica also has more than 17 years of experience designing and building cloud infrastructure management solutions. She was an early and longtime contributor to OpenStack and a maintainer of the Docker project.Follow Erica on Twitter and Linkedin at the below links:TwitterLinkedin Resources:Transcript for Serverless Security with Erica Windisch[00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern AppSec hosted by JB Aviat.Jb Aviat: [00:00:14] Welcome to this episode of AppSec Builders today I'm proud to receive Erica Windisch, we will discuss about serverless and serverless security. Welcome, Erica.Erica Windisch: [00:00:24] Hi.Jb Aviat: [00:00:26] So Erica you you are an architect and principal engineer at New Relic, you are also an AWS serverless hero previously you were founder at IO Pipe, an before that were security engineer at Docker. Right?Erica Windisch: [00:00:41] Ah correct yeah.Jb Aviat: [00:00:42] So thank you so much for joining us today, Erica. I'm really excited to have you as a guest today.Erica Windisch: [00:00:50] Thank you for having me.Jb Aviat: [00:00:51] So, Erica, Serverless as an AWS serverless hero, I guess you know almost everything and you are very, very aware of what's happening in the serverless world. Before we dive in, like some AWS specificities, maybe you could remind us what is serverless and how does it differ from the traditional world, especially from a security standpoint?Erica Windisch: [00:01:14] Absolutely. So, I mean, my background, it's not just Docker, it's building open stack. It's building web hosting services. And, you know, this is an evolving ecosystem that, I mean, in the 2000s was, you know, as simple or as hard as taking your content and uploading it to a remote server and running your application to as complex as running your own servers. Right. And these, of course, are options that are available to you now. But increasingly, developers are moving towards dev ops. They're using containers. They are finding that CI/CD and deployments and all of these things are useful tools for the organizations to move quickly and operating physical machines as pets, as we would call it, versus cattle, which as a vegan is probably not the best metaphor. But, you know, over this time, we've been increasingly going higher level and operating and deploying and building at higher level layers. And serverless is that highest layer in a sense where rather than building a micro service is shipping a service that runs on a VM in a container and a host that you have to manage and operate, even if that's part of a larger Kubernetes cluster.Erica Windisch: [00:02:33] Instead, you just take your application and you give it to your cloud provider and your cloud provider runs it for you. There's a lot of advantages to this, largely that the platform is fully managed for you to a large degree. You know, you don't have to maintain operating system patches. You don't have to maintain Kernels. You don't have to do anything other than operate your application. And really, the biggest disadvantages to this are that you do lose control of managing some of these pieces. But for most users, there's there's a benefit and a game to not having to operate components that are not mission critical or I mean, arguably they're mission critical because your applications are not going to run without a kernel of some sort of however, that kernel can be tuned, it can be optimized, it can be hardened and it can be done by Amazon rather than having to make that your problem, because you and your organization often may not have the expertise or the time to invest in having the same level of security that Amazon can provide out of the box.Jb Aviat: [00:03:36] Yes. So that's the ability for users to focus more on what they know, more like their business strategy rather than their infrastructure, rather than there are server configuration you need. So from this point of view, that's much more focused towards what you knew and what it would do as the cloud provider knows best. Right. So that's a lot of advantages from a security standpoint, because, as you said, it's everything that is a maintenance like security updates et cetera, is dedicated to the cloud providers and its not your responsibility anymore. So is that like the best thing from a from a security standpoint, migrating to to serverless?Erica Windisch: [00:04:14] So I will add an additional caveat here, which is that mean Serverless is a concept. There are multiple products that provide serverless capabilities. Amazon LAMDA being one of the most popular S3, arguably being one of the first Serverless products, and many users are already using S3. So from a certain perspective, you are already using SERVERLESS services and S3 has minimal attack vectors, but there are also large attack vectors. Potentially you could leave your buckets open.Erica Windisch: [00:04:46] I think that actually just today there's big news that this app called Parler, this alternative to Facebook run by right wing conservatives. And what happened there is that they left S3 buckets open, apparently, and they were in the middle of a shutdown as well, and their services were compromised. And one of the things they've done there is having misconfiguration of their applications. They rely a lot on other serverless Services such as Okta, which they're apparently running a free trial of, and they were removed from that service and then they were then in a situation where people were compromising their services because they didn't have many services available. Now, this is a particular case where they were denied for acceptable use policies for what I consider pretty reasonable reasons of being denied service. But the point kind of stands in a way that here is a company that was relying a lot on some of these serverless services and they found themselves still at the mercy of security vulnerabilities despite doing that. And in some ways, it opened up them more to being disconnected, having Twilio disconnect them, having all these other point solutions that were arguably serverless services, shutting them down because they relied heavily on the platforms on which they were no longer allowed to use.Jb Aviat: [00:06:06] So your point is that using serverless puts you at risk of the solution provider?Erica Windisch: [00:06:11] No, not necessarily. No, actually, that's not the point I'm trying to make so much as in they were hacked before they were shut, before they removed some of these services, they were using serverless services and they still got hacked. Right. So the point is more that Serverless itself doesn't ultimately protect you from application level compromises. Right? Right. It does protect you from some of the infrastructure level compromises. It doesn't stop you from other attack factories. Yes, it is true. It doesn't protect you from being bad people and getting yourself kicked off of services. But it also shows that you can use some of these services that are supposed to provide you third party security controls and they can still fail you.Erica Windisch: [00:06:53] Yes, I guess it's multiple points. Obviously, they made a lot of really critical mistakes, both technologically as well as politically.Jb Aviat: [00:07:03] So basically using serverless is not perfect. You can still make like configuration mistakes, security mistakes at various places of the thing. You mentioned also application security. That yes is not prevented by the fact that you are using serverless because the code you are running is very similar to what you were writing in a regular application.Erica Windisch: [00:07:26] Exactly. You're still building applications. So application security is still essential right. If you're relying on something like Okta or Auto0, it's very easy to misconfigure those and to use them incorrectly. You know, it's possible to have Twilio out and not have two factor working correctly or not having it verify phone numbers. Apparently, you can have S3 and you can leave your buckets open. Right. And that is a large part of my point.Jb Aviat: [00:07:53] Yes, absolutely. One of the opportunities I would see with Serverless is that usually you are starting sometimes from scratch, or at least you need a new CI you need a lot of new things when you are moving to Serverless. So that's also a chance for you to use the infrastruc...

Transcribe →

Complex System Security: a CISO Perspective with Emilio Escobar

Dec 16, 202000:41:52Tap to summarize

In this episode of AppSec Builders, I'm joined by DataDog CISO, Emilio Escobar. Emilio's extensive experience at Hulu and Sony Interactive and his contributions to Ettercap all provide a unique perspective on team maturity, managing complex systems across enterprise, leadership insights, security ownership, and becoming the CISO of a public company.Follow Emilio on Twitter and Linkedin at the below links:https://twitter.com/eaescob?lang=enhttps://www.linkedin.com/in/emilioesc/ResourcesEttercap:https://www.ettercap-project.org/https://github.com/Ettercap/ettercapBook Recs:Grit: the Power of Passion and PerseveranceHow Finance WorksHow to Win Friends and Influence PeopleEpisode 3 TranscriptJb: [00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern AppSec hosted by JB Aviat.Jb: [00:00:14] Welcome to the third episode of AppSec Builders today I'm proud to receive Emilio Escobar, who's CISO at DataDog. Welcome and good morning, Emilio.Emilio: [00:00:24] Good morning. Excited to be here. Thanks for having me.Jb: [00:00:24] Thanks lot for joining us. So you recently joined DataDog as a CISO, but you have a broad experience as a security leader, at DataDog today. But before that, Hulu, Sony, and I think you are also the maintainer of a famous tool for security geeks like this, which is Ettercap, right?Emilio: [00:00:48] Yeah, that is correct. I'm one of the three main maintainers of it, and we've been doing it for about nine years already.Jb: [00:00:56] Do you want to share a bit what Ettercap is about? I used it regularly into pentests'. That's an amazing tool.Emilio: [00:01:02] Sure. Ettercap has been around for a long, long time, I think, since 2006, and it had slowly died down in around like maybe two thousand eight, two thousand nine. But it is a man in the middle attack tool. It's leveraged by a lot of pentesters for doing man in the middle attack to their customers and trying to obtain credentials for for services like SSH Telnet and what have you. How I got started with it was that when I worked at Accuvant Labs, I was a pentester, one of my colleagues was using it or trying to use it for an engagement that he was working on. And he was running into some, some bugs. And he reached out to me and asked me if I knew how to code in C. I said yes. And he's like, I'll give you five hundred dollars for if you solve these two for each of these two bugs that, that I'm running into. So looking at the code, I was able to fix the issues that he was running into. I never got that thousand dollars back. But what that started was the conversation between him and I. This is Eric Meilin, who I believe is that BlackBerry now about like, hey, should we actually resume the support for Ettercap? We wanted it to work well in MacOS. We wanted IPv6 support. We wanted all these new features that it wasn't supporting. And we reach out to ALoR and NaGA the original authors and they were gracious enough to allow us to to run with it as long as we kept it open source. Right. And that was the commitment that we gave them. So fast forward nine years. We've we've added a few versions. Now, I'm less involved in the coding because I really don't just don't have the time for it, but surrounded by two people who are active. So feel free to check it out on GitHub and submit pull requests, issues or use it and give us feedback.Jb: [00:02:51] Amazing. Yes great tool, I used it a lot. So after being a pentester, you went to Sony, Hulu. So two companies in the entertainment world.Emilio: [00:03:34] Yeah. Yeah. So I actually met PlayStation during my consulting days. Right. For some engagements that we did with them and,and a few years later they reach out to me and said, hey, we're looking for to grow the team, we're looking to grow the application product security side of the house. So I joined as employee number two for, for that discipline. And we were able to grow it to a pretty significant team. We were able to build capabilities also out of the Tokyo office out of Europe. So it was it was pretty good program. The team is still growing, is still active. And it was a lot of fun. It was. But it was the first time that I was on the receiving end of attacks from groups like Lizard Squad Anonymous. Right. So PlayStation is a big target and things like fraud and fame and fraud and all those things were a lot of the factors that we had to go sell for. So really, really interesting set of challenges like gaming faces right up. Time is everything. And we have a very opinionated customer base. Right. Like gamers care and they will let you know pretty quickly, I guess.Jb: [00:04:38] And yes, Sony has been in a couple of important leaks were you in the company when that arrived, it must be insane to live that from the inside.Emilio: [00:04:46] I wasn't part of PlayStation during their big outage. I supported them as a consultant. I joined after as an employee and for Sony Pictures, theyre a separate entity, right. So we collaborate, but for something like what happened to them, it's thanks but no thanks kind of approach from them. Right. And rightfully so. And I think they had the right support from the FBI and everyone else involved in their investigation. So we only supported from building a discipline and a practice, but not. Step out of the way and let us do what we do, because they have a pretty good team there as well.Jb: [00:05:16] Yes, OK, interesting. And so then it was Hulu when we first Emilio you were looking at Hulu and I guess that there you had like very distributed architectures. Right. Would you mind sharing a bit about the context at Hulu?Emilio: [00:05:32] Yeah, certainly so, yes. I joined Hulu to grow and build a security practice there and with a very heavy emphasis on product development. So SDLC security. How do we enable velocity? Time to market is everything, you know, obviously for a streaming platform. When I joined Hulu, we were working on the live TV product, so uptime became even more of a concern. Right. Video-On-Demand, if you can watch a video now, you might try in an hour. But live TV, if it's a Super Bowl or the World Cup or what have you, you want to watch it when it happens and not sometime later, unless you purposely record it because you can't watch it when it's live. So uptime was a big concern. So joining Hulu, I discovered the complexity of the architecture right. It was a complete microservice environment. At PlayStation, they were working towards microservice and segmenting things in smaller type of workloads. Hulu had that built. So dealing with that complexity was something that I wasn't faced with at PlayStation. So it just required a different approach of security, right. Everything was automated. Hulu had a platform as a service framework built by Hulu, which was really interesting where developers to get push can push a production and the containers will get built out and everything. So I thought all the right things were in place. We just had to get security in them to make sure that things were done appropriately. But we had to we had to rethink the whole legacy approach to security, of being a gate, doing code reviews and, you know, how do you do static analysis? How do you do dependency scans and all those things? Because you know a developer can get push any time and they were doing over three hundred deploys a day to production. Right. So it was a lot to catch up to.Jb: [00:07:14] And could you could you give us some numbers so we can see the scale of that, like how many developers, applications, repositories, if you have that in mind.Emilio: [00:07:23] Yeah, yeah. If I remember correctly and I'm sure it has changed since, but I think that towards the end of my Hulu tenure we had over 600 developers and I believe the number was around twenty-three hundred microservices. Now, whether that's the right number or not, that's a separate conversation. Right. But that was what we were dealing with and language frameworks were all over the place, right. So we wanted developers to be creative and effective in whatever language they felt the most comfortable with. So we had to support JavaScript, Python, Golang, I believe we have som...

Transcribe →

Framework Security with Ksenia Peguero: the paved road foundation

Nov 4, 202000:41:34Tap to summarize

In this episode I’m joined by Ksenia Peguero, Sr. Research Lead at Synopsys, for a discussion around frameworks and the foundational effect they have on the security of your application. We’ll share concrete tips for upgrading your security through your framework, choosing the best framework for app security, performing a framework migration, and how to spot and fix security blind spots in your frameworks.Resources:About KseniaKsenia Peguero is a Sr. Research Engineer within Synopsys Software Integrity Group, where she leads a team of researchers and engineers working on static analysis and security of different technologies, frameworks, languages, including JavaScript, Java, Python, and others. Before diving into research, Ksenia had a consulting career in a variety of software security practices such as penetration testing, threat modeling, code review, and static analysis tool design, customization, and deployment. During her decade in application security, she performed numerous engagements for clients in financial services, entertainment, telecommunications, and enterprise security industries. Throughout her journey, Ksenia has established and evolved secure coding guidance for many different firms, developed and delivered numerous software security training, and presented at conferences around the world, such as BSides Security, Nullcon, RSA, OWASP AppSec Global, TheWebConf, and LocoMocoSec. She has also served on review boards of OWASP AppSec USA, EU, and Global conferences.https://www.linkedin.com/in/kseniadmitrieva/https://twitter.com/kseniadmitrievaKsenia Presentations:https://www.youtube.com/watch?v=Ku8mPXmX7-Mhttps://www.slideshare.net/kseniadmitrieva/how-do-javascript-frameworks-impact-the-security-of-applicationsAdditional Resources:Passeport, Flask loginhttp://www.passportjs.org/https://flask-login.readthedocs.io/en/latest/Sails CSRF protectionhttps://sailsjs.com/documentation/concepts/security/csrfExpress CSRF pluginhttps://github.com/expressjs/csurfDjango / React security page https://docs.djangoproject.com/en/3.1/topics/security/https://guides.rubyonrails.org/security.htmlKsenia Angular listing rules https://github.com/synopsys-sig/tslint-angular-securityW3C security WGhttps://www.w3.org/2011/webappsec/Levels of vulnerability mitigation: https://image.slidesharecdn.com/javascriptframeworksecurity-amsterdam-191008173330/95/how-do-javascript-frameworks-impact-the-security-of-applications-7-638.jpg?cb=1570556143Episode 2 Transcript:[00:00:02] Welcome to App Sec Builders, the podcast for practitioners building modern AppSec hosted by Jb Aviat.Jb: [00:00:10] Hello Ksenia, nice to meet youKsenia: [00:00:14] Hi, Jb, how are you doing? Jb: [00:00:20] I'm great, thank you. So, Ksenia, you're a senior research engineer at Synopsis.Jb: [00:00:24] You led a team of researchers and engineers working on static analysis. Before Synopsys. You've had a consulting career where you did penetration testing, threat modeling, code review, and you are also a seasoned speaker at various app security conferences across the world, such as the famous OWASP AppSec. So could you tell us a bit more about you and what you enjoy in the AppSec field?Ksenia: [00:00:49] Sure. Well, I come from an engineering background. I was an application developer in the gaming industry for about five years. And then I came to the United States to do my masters.Ksenia: [00:01:01] And the last year I got an internship with Cigital that used to be called Cigital, a consulting company as a security intern. And I never went back to development. That was absolutely fascinating career because as a consultant, as a security person, you always need to learn new things. So I did consulting for about seven years and kind of went up into the ranks of principal consultants. And then I pivoted and started to dig more into the research and security research. And around the same time Cigital was acquired by Synopsys. So now I work in Synopsys. So pretty much with the same company, with the same people, with a different name. But now as part of the security research lab, as a security engineer.Jb: [00:01:47] Super cool. You mentioned the gaming industry. Ksenia, so did you develop anything popular, famous?Ksenia: [00:01:55] Well, that was many, many years ago and I was developing games in Flash. Adobe Flash.Jb: [00:02:03] Oh, my God.Ksenia: [00:02:04] So, you know, the little match, three type Tetris type games for housewives and people at work.Jb: [00:02:13] All right. That could be a nice introduction. Yes. That's how I got into security by hacking flash in the browser, but maybe not.Jb: [00:02:24] Ok, and so you were actually in the middle of a PHD thesis, right?Ksenia: [00:02:29] That's correct. Hopefully closer to the end. But yes, in parallel with my full time job, I'm also doing a PHD and I'm working on guess what? Security research and on framework security specifically.Jb: [00:02:45] And so how do you feel academic research is helping application security moving forward today?Ksenia: [00:02:51] It's interesting. I feel like - because I have a lot of experience in the practical field, I hope - I feel that I bring a different perspective into the academia because a lot of the research that there is and academia, at least in the last 10 years, a lot of the research was focusing on exploits, on finding vulnerabilities, which is great because people in academia spend a lot of time, you know, finding those new vulnerabilities, new types of attacks, especially on more complex concepts like crypto attacks, for example.Ksenia: [00:03:25] But until about now, academia wasn't focused much on fixing the problems that they find. So with my background in security consulting, where we not only find the issues, but we help developers to fix the issues, that's what I'm trying to bring into my research. How do we actually get rid of the bugs and not just find the bugs?Jb: [00:03:47] Yes so basically more shifting left, right?Ksenia: [00:03:51] Exactly. Yeah, exactly.Jb: [00:03:53] So helping academia futures shift live to great outcomes here. So this extensive research that you've done on frameworks, so you presented it recently at AppSec Cali. So in your research, you found that some frameworks made it easier than others to introduce certain categories of vulnerabilities. So would you mind telling us a bit more about that?Ksenia: [00:04:15] Sure. So as part of my research, I was focusing on JavaScript and I started with the client-side JavaScript frameworks or template engines, and then I switched into server-side JavaScript frameworks and I looked at different vulnerabilities.Ksenia: [00:04:30] And the hypothesis was that if the framework actually has security controls or mitigations built-in, then the applications would be more secure than if they're not. So it's kind of a native idea. But with the help of the categorization framework developed by John Steven, I divided the places where the mitigation can exist into different levels. So we start with a level zero where there is no mitigation and code is vulnerable. And oftentimes that happens when there is no framework in use at all. So everything is written by developers from scratch and then we go into the next level of a custom function that developer has written and then into a third party library that developer is using and then into a framework plugin, so something that works very tightly with a framework and then the next level of the mitigation is built into the framework. And then actually there is another level that I discovered throughout my work is when the mitigation is built into the language, programming, language or platform itself. And of course, as far as you go closer to the framework or closer to the architecture level, those vulnerabilities will be fixed and it's less likely that they wil...

Transcribe →

Solving Race Condition Vulnerabilities with Tanya Janca

Oct 14, 202000:39:09Tap to summarize

In our inaugural episode, we sit down with Tanya Janca, founder of WeHackPurple, to discuss her expertise in solving for Race Condition vulnerabilities during her career as both a software engineer and application security professional. We spend some time talking through the most common types of Race Conditions, review a few real-world hacks and vulnerabilities, and present actionable tips security and technology teams can make to solve this class of vulnerability. About our Guest:Tanya Janca, also known as SheHacksPurple, is the author of ‘Alice and Bob Learn Application Security’. She is also the founder of We Hack Purple, an online learning academy, community and weekly podcast that revolves around teaching everyone to create secure software. Tanya has been coding and working in IT for over twenty years, won numerous awards, and has been everywhere from startups to public service to tech giants (Microsoft, Adobe, & Nokia). She has worn many hats; startup founder, pentester, CISO, AppSec Engineer, and software developer. She is an award-winning public speaker, active blogger & streamer and has delivered hundreds of talks and trainings on 6 continents. She values diversity, inclusion and kindness, which shines through in her countless initiatives.Founder: We Hack Purple (Academy, Community and Podcast), WoSEC International (Women of Security), OWASP DevSlop, OWASP Victoria, #CyberMentoringMondayResources:About the vulnerabilities discussed:The Starbucks infinite credit race condition: https://www.schneier.com/blog/archives/2015/05/race_condition_.htmlThe Gitlab ‘merge any pull request’ race condition:https://www.cvedetails.com/cve/CVE-2019-11546/The Dirty Cow vulnerability: https://dirtycow.ninja/ with the research paper: http://www.iiisci.org/journal/CV$/sci/pdfs/SA025BU17.pdfThe Spurious DB race condition, impacting all major operating systems: https://www.triplefault.io/2018/05/spurious-db-exceptions-with-pop-ss.htmlTools discussed:Safe Rust race condition guarantees: https://doc.rust-lang.org/nomicon/races.html#data-races-and-race-conditionsGoLang race detector: https://blog.golang.org/race-detectorTesting race conditions on REST APIs: https://github.com/TheHackerDev/race-the-webLinks for Tanya:Tanya's book Alice and Bob Learn Application Security: https://www.amazon.com/dp/1119687357/https://shehackspurple.cahttps://twitter.com/shehackspurplehttps://www.youtube.com/shehackspurple  https://dev.to/shehackspurplehttps://medium.com/@shehackspurple https://www.youtube.com/shehackspurple  https://www.twitch.tv/shehackspurplehttps://www.linkedin.com/in/tanya-jancahttps://github.com/shehackspurple/https://www.slideshare.net/TanyaJanca/Tanya mentioned she’s also a professional musician, you can find her amazing rock band here! https://www.youtube.com/watch?v=zI6Mh2-E_CQLinks for We Hack Purple:https://wehackpurple.comhttps://twitter.com/wehackpurplehttps://www.youtube.com/wehackpurple  https://linkedin.com/company/wehackpurplehttps://newsletter.wehackpurple.com Tanya also shared about https://www.clouddefense.ai/ their new company just going out of stealth.Transcript:[00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern Apps hosted by JB Aviat.Jb: [00:00:14] Welcome to the first episode of AppSec Builders. I'm Jb Aviat, and today I'm proud to welcome Tanya Janca to discuss race conditions. Race conditions are a common class of vulnerabilities in APIs or applications with business logic, which are very well known. For instance, they aren't part of the OWASP top 10. Tanya Janca will tell us more about the application security book she just finished writing, and about her company that just came out of stealth mode.Jb: [00:00:44] Our guest today is Tanya Janca, also known as SheHacksPurple. She's the founder of We Hack People, an online learning academy dedicated to teaching security, DevSecOps, and cloud security. Tanya is devoting a lot of her energy to democratizing security. [00:01:00] She also is the host of an amazing podcast where inclusion and diversity shine through. You have experience working at several software companies such as Microsoft, Adobe and Nokia, and have had varying rules across security and engineering throughout your career. As pentester, CISO, AppSec engineer and software developer. So Tanya, I think you wrote a book, recently. Would you like to tell us a bit about it?Tanya: [00:01:27] Yes. So my book is called Alice and Bob Learn Application Security. Do you remember the characters of Alice and Bob when they first explained what encryption was?Jb: [00:01:38] Of course, who doesn't?Tanya: [00:01:41] Yeah, so and whenever I would give examples I would always say, you know, it's not Alice's fault or or Bob's fault.Tanya: [00:01:48] It's that a safeguard was broken. And that's how this happened to Alice or there was a security header missing and that's how it happened to Bob. And so I would always weave them into things. And when I was trying to decide what to name [00:02:00] of my book, that was all about application security. Well, all my examples will be Alice and Bob. So maybe it should be called Alice and Bob Learn. And it's a text book written in casual language to try to make it really easy to understand. And it's basically the very beginning of AppSec, like how to do security requirements, how to design a secure web app, what is secure coding and what are all the things I need to do? What does that security header mean and why do I have to have it all the way up to, you know, all the different types of security testing, all the different types of tools or activities that exist, how to build an exact program?Tanya: [00:02:38] Basically, I was like, I'm going to take my brain and put it into a book. With jokes.Jb: [00:02:44] Who's the ideal reader of your book, that developers interested in security, AppSec engineers?Tanya: [00:02:50] I would say definitely an AppSec engineer would want to read the book or any software developer. I would say that other areas of I.T. that want to [00:03:00] know about security should read most of it. So there's a bunch of chapters like "How to secure your own digital privacy" and things like that, and the ideas of what is secure design and what are all these security concepts and what do they mean and how do I apply them? And I would say at least half of the book, almost anyone in it, could easily read and understand. But then there is two chapters that are just like, here's a lot of code. I'm getting really nerdy and I can't help it.Jb: [00:03:31] So you sent me to the table of contents of the book and I really enjoy r...

Transcribe →

All episodes

Developers vs. Security Training with Jim Manico

Are Cloud Vendors also Security Vendors? with Sarah Young

Shift Everywhere with John Steven

Serverless Security with Erica Windisch

Complex System Security: a CISO Perspective with Emilio Escobar

Framework Security with Ksenia Peguero: the paved road foundation

Solving Race Condition Vulnerabilities with Tanya Janca