Uncovering The Secrets Of Threat Modeling With Brook Schoenfield
TLDR;
- Threat Modeling is a continuous activity and should be part of every phase of SDLC starting from Design phase itself.
- For Threat Modeling, start with something as simple as STRIDE framework and as the organization matures, review and utilize other frameworks as needed.
- For resource constrained organizations, start with Open Source like Semgrep or use Community versions of Security tools to improve Code Security before investing in Wholistic & Expensive Tools.
Transcript
Host: Hi, everyone. Thanks for tuning into season two of Scale to Zero. I'm Purusottam, co-founder and CTO of Cloudanix. Today's episode is focused on application security, threat modeling, ChatGPT, and much more. To discuss on these topics, we have Brooke Schoenfeld with us. Brook is the CTO at Resilient Software Security. Over the last 20+ years, he has built and led multiple AppSec programs. Brooke is the author and co-author of six books on software security and has contributed to numerous industry efforts including the Threat Modeling Manifesto. He originated the term developer-centric security and just good enough risk rating. He's also on the faculty of the University of Montana. Brooke, it's wonderful to have you in the show. For our viewers who may not know you, do you want to briefly share about your journey?
Brook Schoenfield: Sure. I was in high tech being a programmer. I loved programming. And I loved designing. And my boss said, hey, could you do the access control lists on our internet connection? This was in maybe 1998, I think. So I've been around a while. And I said, sure, because I was writing our TCP IP stack at the time. which, you know, think about that. I knew something about networks. It turned out when I got to Cisco that I didn't know anything about routing networks, but I thought I knew something about networks. And I do, I really do, because I have written TCP IP stacks. I know how it works, down to the hardware level.
So, you know, he said, you do networks, you could do this. And I went, sure. Ha ha, of course, more and more security things would come in. until I was the security manager along with my day job as a chief designer at this software house. So yeah, it was kind of an accident. I kind of backed into it.
And then Cisco hired me to look at what we now call to dream, literally to dream was a great job, to dream about what we now call security information managers, SIMs, and, you know, what would they look like? How would we do things like that? It was a great job. I loved that job. It was so much fun. But it wasn't really producing much. And Cisco, the .com bust happened and Cisco needed to get rid of people and they didn't want to get rid of me.
So they said to me literally, they literally said, we've been trying to hire an application security architect. for the last 18 months. And you've developed a lot of software and designed a lot of software. We know this isn't the kind of job you're doing right now. We know it's kind of not that important, but would you be willing to take it?
So they offered it to me as a downgrade, literally, not knowing that, you know, in three or four years, we would be one of the most important teams in InfoSec because attacks change, right? and attack vectors changed and things started getting into the web messages. And so that's kind of how I got into this. So then I built my very first application security program in around 2002, 2003, 2001, 2002, 2003, 2004. Built the first champions. It's not the first champions in the industry.
But we independently invented the idea of Security Champions there and built a program in 2004, 2005. One of the first web application security scanning programs, which by the way is still running almost 20 years later, which is really a surprise. How often do you build a program that goes for 20 years? I have nothing to do with it. I left Cisco in 2011. But still, that's kind of the beginning and somehow the security bug got me. It really got me. I realized what I was doing was actually kind of important and it mattered.
It mattered not just to Cisco. It mattered because as John Stewart who was then CISO at Cisco once said to me, yeah just to keep this stuff usable would be great and and I kind of got the bug that that I could do something, my little part of it might actually matter to the greater good. And of course that always helps one come to work in the morning and do stuff maybe one doesn't so much enjoy. And so that's kind of my journey. And then
Host: That's an interesting way to get into security, right? Even though like accidentally you got into security and now that is your passion area, right? In a way. So, I'm looking forward to unpacking like learning some of it as part of this discussion.
Brook Schoenfield: That's very sweet. Thank you.
Host: So the way we do the podcast is we have two sections. The first section focuses on security questions, and the second section is focused around rating security practices. So let's start with the security questions. So,
When it comes to software development, most organizations are familiar with the SDLC models. But from a security perspective,
What's your take on how soon should threat modeling be introduced into SDLC?
Brook Schoenfield: Right from the start. It should be fundamental. In Core Software Security, where I wrote chapter 9, we talked about the heart of security practices and at that time, that was 2013-2014, when we were writing that, I was thinking you got to get static analysis and code review going. You got to get something around the code. And that's the most important part. My thinking hasn't changed, but Over the years since then, and I was building a threat modeling practice, the fourth one I've built at McAfee at the time,
I was thinking of threat modeling still as something a little more discrete than it actually is. My thinking has evolved a lot. Threat modeling is fundamental to thinking about security. In fact, it's fundamental to life. If you've... If you conduct a vehicle or walk in a city late at night alone, a strange city, you have a threat model.
You probably don't think of it that way, but hopefully you're not on the road without a threat model because bad things can happen, right? And so that's a threat model.
It's a very simplistic and daily life kind of thing that we all, most of us at least, have to encounter and deal with. And I use those two examples to try and get us all to realize that you can't think about security without thinking about what could go wrong, what bad things could happen, what exists, and then how we're going to protect against the bad things that we think might happen and how likely they are to happen.
All of that is just prep modeling, really simple. And whether you're the see-saw thinking about where do I put my investments? or you're a developer thinking,
I want to write this feature and I need to do this story, pulling it off the backlog if you're working in agile, you're really still thinking threat modeling and it's just fundamental. And once you do that, you realize all we have to do is help people get better at it. Rather than saying, do threat modeling and make it all great. You know, back in the day, I'm just going to do a little side thing that I think highlights this shift.
Back in the day, our security development life cycles or SDL or SDLC, depending upon what you like to use, they used to include a lot of steps, architecture steps and design steps, that would be an engagement. Does this need security? Then I want to review your architecture. Now I want to review your design. Now I want to check that you got all the right requirements in. Now you're going to develop, and then at the end, we'll do a go live with all these steps. And when I was sitting at, and it's very complicated, and developers go, oh my gosh, what is all this stuff? I don't understand. I just want to design and write the code. Right?
Well. This works much better if threat modeling is just part of how we think about building software. In the same way you'd consider scalability or performance, you know, usability, these are all things you have to consider. Well, we have to consider security. What my friend Isar Tarandash calls the star illities. And security is one of them. And when you change it from these special things to, oh, we're thinking about what stuff we have to build and how we have to build it. and we consider security as part of that, you're threat modeling. But don't make it so special.
Unfortunately, in order to do this well, there's some very specialized knowledge you need to have. And that's where we stumble, not that it's fundamental to what we do. And I'll just say, I talked to a lot of developers, and while this is anecdotal and not a scientific survey, I haven't met a developer in years who looked at me and said security, that's somebody else's problem. Not in years! And that's a good thing. That's a wonderful development to say. I haven't walked to an organization that said, we start to engage about security, and they go, no, no, security. We don't need to worry about that. Everybody knows it's a problem.
The specialized knowledge is understanding which attacks or threats, as we often say in threat modeling. which attacks are relevant to a particular tech stack and architecture and set of inputs. That's a very specialized knowledge, which is not at this moment easily attained or gained. Unfortunately, if it was easy, it would be great.
My friend, Adam Shostak just published a new book called Threats, which I highly recommend to everyone because he's trying to solve that problem and make it easier. Things like the card deck, elevation of privilege, help. Think about stuff that you don't know about that could go wrong. But that's one of the big problems.
And then another problem is risk rating, which is rather difficult to do and not well understood. People call vulnerabilities risks. They're not. That's not a risk. That's a weakness that contributes to a potential risk. And, you know, we won't go into risk grading right now. You can go look at some of my stuff or, you know, some of the people are fair, the open group standard or whatever, and learn more about that.
But the vulnerability by itself is not a risk. And that's a misunderstanding that we have all the time. So that's another stumbling special knowledge that we need in order to threat model well. And then the last stumbling block is... many defenses are end to end, that is, many to many relationships to attacks.
So there are a few attacks where you do exactly a thing and it fixes it. Or weaknesses. And you can fix a certain vulnerability with a certain thing and boom, you're done. But with lots of them, we build up a defense that sort of closes off the attack service and then sort of makes it more expensive to pull highlights that an attack is happening through monitoring, and we use all these different strategies together to build what we call the defense in depth. And understanding how to do that is a bit specialized.
So those are the three stumbling, big stumbling blocks. And you know, this, what I'm saying comes from the fact that happily I've had the honor to teach a lot of people how to threat model in my career. And so I have... observed what the stumbling blocks are and those are the big stumbling blocks. So that's where you need some specialist help, right? And so that helps if you can call on the specialist.
But people learn, I mean, when we have developers, when we teach developers how to threat model, yet first their threat modeling is a bit limited. But over time, they learn what's relevant if they get some help and they get better at it and pretty soon you... They don't need the specialist anymore. They know what the threats are they need to worry about for their particular piece of software. And so, that's where developer-centric security gets.
Host: Right, you highlighted specialized knowledge. How can, where can let's say developers or security engineers go to learn about these specialized like get specialized knowledge? You highlighted like Adam's book. Similarly,
Are there any other avenues where security engineers can go and learn these?
Brook Schoenfield: Well, that was the whole purpose in writing securing systems was to provide exactly that sort of, here's how you think about a system. And the heart of it is case studies of typical architectures you might run into. They're all fictional, so I wanna get sued.
But I started with real architectures and realized, oops, somebody's gonna get mad at me if I put this into a book because I don't own it. So I... I took the architectures I knew and then created, you know, slightly fictionalized versions of them so I wouldn't get sued by people.
But they're all architectures, essentially, I have encountered in my career. And so that was one way of going about it.
Adam's book is another approach. There are a few other places to go. Mitre's ATT&CK, or ATTAC, tells you what has actually been used in the world And it has lots of twiddly ways to look at it in interesting ways. So that could help. And it's tied to the defense through an ontology. So that's a help.
Things like MITRE's CW common weakness enumeration is generally too detailed for this. We need to come up to another level. But it has some organizing principles that might help. climb out of your, out of, you know, limitations and understandings. And there's, you know, uh, common attack pattern enumeration, KPAC, um, also by MITRE. And again, it's a bit detailed.
And so that's, that's one of the problems we run into, but do you have organizing principles that I've used a lot in my training? And then there's something like stride. If you have no idea what to do, at least think through the you know, spoof, tamper, I'm blanking, it's not, information disclosure, I'm skipping the R because I can't think of the right word, I keep thinking remuneration but that's not the right word, my brain is having a burp there. You can use stride and I have taught, I use that as a kind of a... a gateway, if you will, into this, that might help.
But I've found, even Microsoft don't use it anymore because they've found that it's too general. You need to get more specific. I have literally seen professional, supposedly professional threat models where the letters S-T-R-I-D-E were written by every input with nothing else in them. No, that doesn't help.
That does not help at all. You really have to get more specific. But Stride might, for those uninitiated, get you starting to think about the things that go wrong. Another thing is the elevation of the privilege card deck. Again, Adam invented that And it's free. You can download it. You can also buy the deck, but you can just download the PDF.
And just running through that might give you some ideas about how to get around this. So I'm encouraging people to the threat model. You don't need an expert, but your threat models will be better if you get some expertise or follow some of these things.
Try playing the elevation of privilege game or just have the cards and go, does this apply? Does this attack apply? Does this not?
Literally when I got to Cisco, it's a true story. When I got to Cisco, I was working with people like Michelle Gell. and she was Michelle Crabb when she did the Morris Worm in 1988. Oh my gosh, serious, serious, you know, security expertise. And Steve Acheson, inventor of Make the Easy Path, the Secure Path, and a number of other things.
And when they started talking about security, I realized, oh my gosh. I don't know as much as I thought. I actually felt really small, really dumb in the presence of these people. So I actually read the first version of Hacking Exposed to and from, because I was taking public transportation for part of my commute, to and from work to Cisco.
Every day I was reading Hacking Exposed and run as fast as I could and catch up. So something like Hacking His Spells books. might help you, they certainly help me run and catch up with these amazing people and learn enough to be able to speak code with them and do my job. All of these things are good. They're all help, but none is quite the right thing, I find.
Host: I was just looking at Stride, its spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privileges..
Brook Schoenfield: yeah, repudiation means I hide what I did because usually we talk about non-repudiation and that's what something like a signature and a hash, cryptographic hash give us. They say, no, the owner of this private key is the one who did sign this.
And so that's non-repudiation. And so they it to repudiation to say, look, I, the attacker, I, the wily attacker didn't do anything. You can't see me. So you wanna look for opportunities where you, they can hide, if you will, what they've done. And that's what that means. Something didn't happen.
Host: So you highlighted stride and MITRE attack framework and other frameworks, right? And each of them, as you highlighted that they have pros and cons in a way. So unless you have a security expert in your team, it's hard to understand which model to follow, right? How should,
Brook Schoenfield: I need to interrupt here because they're not models. They're just resources. Stride is a model. expertise is a model for ATT&CK, but the others are not models, they're just resources. I just really wanna be clear about that. They might help if you take a look at them, they might get you out of what... The big problem here is not that people can't think of attacks. They're limited to the attacks that they can think of. And it's usually tasked to do with the functionality and the data that they have.
Not that that's not important. It is. But let me give you an example. There are attackers who just want your computing power. They don't care what your system does.
Two examples of that would be crypto mining. or but net that is I have a whole bunch of machines that I control and I rent them out to do things like send out spam or move illegal pornography around or stuff like that. And I rent them out. And that's a business model.
That's an attacker business model. So I don't care what your stuff does. If I can take over your machine, it has business value to me inherently. And I don't really care what your system, what you're doing with them, or your data. something that's often a really big surprise, people go, oh yeah, right, right, we need to think about that.
But they don't necessarily think about it at first because it's a little, what's the word I want? It's just, we stay limited by our vision and that's where security comes in to go, yeah, I know what the range of attacks are. And, you know, one of the things
I often point out is, Authentication is important, but it doesn't stop attacks. It narrows the attack surface and also allows us to attach bad behavior to an account. And so that's important. I'm not saying it's not important, but in many scenarios, it's not going to prevent attacks in the way that people often think it does. So that's where the expertise comes
Host: One follow-up question I have on this is you highlighted that it should be done,
Threat modeling should be done as early as you can but should it be done like once or it needs to be done on a continuous manner. What's the recommendation there?
Brook Schoenfield: As you build software from idea and actually through testing, there's a play for the threat model. And let me run this down. Yeah, but don't think of it as phases. Because in Agile, a lot of this stuff happens in parallel, and it doesn't make sense. But if you have phases, yes, in phases. But often, software delivery, software creation, and generation is not linear. There's a lot of parallels. Depends.
But the point is, as you begin to have an idea, I think we should build an X. You want to think very highly about, well, how might people misuse this? And what will our stakeholders expect in terms of protection? That's very high level. And it gets you. That's threat modeling. but it's very, very high level. And it's at different levels. So compare that to, I'm writing this feature and I want to do it a certain way and certain ways are weaker from a security perspective and certain ways are stronger from a security perspective.
Take whether I should just have one authentication token or if I should have an authentication token. that expires in a refresh token, which is a better system. And thinking about that at that specificity is also threat modeling, but it's really specific. So I would say instead of thinking about doing threat modeling in a repeat way, you're just building the model and refining it as you go.
And it does get more specific for each story. or each feature. But you're still, someone may be coming up with a new idea, and so they got to be threat modeling at that level at the moment that somebody else is doing something really specific, and they need to be very specific about the modeling to that particular point. But it's the same model.
We're just refining it, and we're just building it and adding to the materials rather than thinking of it.
The worst is. The security person drops in after the design has been mostly completed and people are busy coding like crazy and the security person drops in, takes a look at the design, writes up a bunch of requirements that nobody knew about and drops them on the team and says you got to build this stuff too, whether it works with your design or not and walks away.
That is death… to threat modeling. It will really, really disturb everyone. And the thing is the security people don't like that either. I can't tell you how many times I have sat in a room with developers and security people and asked the developers, how do you like getting your security requirements halfway through or late in the game?
And they're like, oh, we hate it. And then I asked the security people, so how do you like getting called in so late? that you're dropping, you know, you can't, you feel really ineffective and you can't get it, get stuff done and there's a lot of friction. And they say, we really hate it. And then I look at them and I say, why are you doing it this way?
You know who each other are. It's simple. When you're starting something new, call your security person. Security people reach out. What new is coming down the pike? You can solve this problem. And that's actually the only way I ever see that problem get solved. But the once at a time, what model point in time is a really old fashioned thing that just doesn't work today. Really think about continuous delivery.
We're changing the software constantly. It just doesn't work.
Host: one thing that I see from your response is that it has to be done as a continuous practice. It cannot be a one-off activity and you are done or it cannot be that your design is done then you're doing the security review but rather it should be more of a collaboration between security team and the engineering team when the design is getting done or the requirements are getting finalized or even when the dev is going on or testing is happening. sort of in every phase and which would mean there has to be resources put in place, right? Either in terms of time, people or budget. So I just want to get your views.
Let's say if it is an early stage startup, they're constrained by some of these, right? Either time, people, or budget. What areas of security should they focus on?
Brook Schoenfield: That's a great question. And I actually am supposed to deliver a webinar about that sometime this year. So I'll just pitch the fact that at some point through Resilient, we're going to have a webinar on this very subject.
Obviously, you may not have the right expertise in-house. And so that's a problem. You do, I encourage everyone to do the best they can, even with limitations. A, the most important thing is get some kind of security testing, tooling going. That's very important.
You know, open source, even if it's a little noisy, it will help. So that's number one. So you can at least know if you're building weaknesses in your code. and get some sort of threat modeling to the best of your ability, just as you just said. Just as you just said.
Go through it and to the best of your ability, think through, as Adam likes to say, the four questions.
- What are we building?
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- And have we done enough?
And that pretty much sums up the best you can do.
You know, if you get more money, you can always bring in someone with a lot of secure, you know, threat modeling experience as a consultant. They can be sort of a part-time security architect for you. There's a bunch of companies that will do that. I'm not going to pitch money particularly. There's lots of great architects out there who would be happy to come in for, you know, a modest amount of money, hopefully. The big four accounting houses want $100,000 in engagement, so maybe that's out. But there are other people out there who will help you if you think you can afford that.
But oftentimes at the very beginning when you're self-funded, there's no money for that. But the other thing I wanna say is a couple of the major commercial tools, threat modeling tools, and I forgot to say this before, when you asked this question. have community versions. And they have a catalog of threats and defenses.
So I'm not pitching any particular tool here. There are a couple of really good ones and they have community versions that you can just go to today, download for your startup and try to enter in as much as you know about what you're building and see what they say. That can get you over the and it's free to a good home. You do not have to pay anything for this. That could help, and that could be great.
And I also wanna mention Threat Modeling Tool from Microsoft, it's been out there for nearly a decade now. It's also free, it's not open source, but it's free. And it might get you over the hump if you produce the right kind of software. It's not very SaaS oriented or cloud oriented. It's a little more operating system and application, end point application oriented. But it could help. These are all things that the startup not only can do, but must do, frankly,
What happens if you don't do these things? Can I just finish this one sentence? If you don't do your threat modeling, you will have built something that probably has weaknesses that then you're going to have to rebuild. And that's going to be much more expensive.
Host: That makes sense. I have one follow-up question. So generally in a startup, right? Again, going back to the constraints that they have, when we want to bring in security, it's often seen as a deterrent to growth, like it extends the development cycles or it delays product rollout sometimes because you have to incorporate some of the security features. So how do in that case,
How do you, sort of justify the effort and the cost to your management saying that hey, security is important? We need to build it as part of our development cycle rather than doing it afterwards. So how do you justify that effort and cost?
Brook Schoenfield: Well, you know, I think that's actually kind of a bit old-fashioned problem because of all the public breaches that have happened over the last seven, eight years. We've got mind share. You will run into that from time to time. You will. And I don't don't want to dismiss your question entirely.
And if you're working at, you know, I mean, what did Home Depot say until they got hacked? We don't produce security, we produce hammers until they got hacked. That was, I think, in 2016 or something. But there is that, but a lot of that is changing.
And especially at startups, most, again, most developers I have talked to, again, not a formal survey, but anecdotally, I'm not finding a lot of... oh, that's somebody else's problem or proof to me you need to do that. It's more, prove to me I need to make this particular investment. And then you get into real specifics.
And one of the things that I try to do in my practice is to provide a ramp. A ramp from, look, there are these open source tools. They have their problems, but they do something, and they get you started, and they're easy to work with. and start there and then we'll build as you build revenue, we can build on that.
And so you've already laid a foundation. People are already doing security and it's just integral to the process. I mean, if you have get, you can stick with a get action, semgrep on your code, if you're working in the right languages that semgrep covers, you know, today, if you're working in get, go in GitHub. go use a GitHub action to say, scan my repo with Semgrep. You've started.
You see, it's not that hard to get started anymore. It used to be like, you know, you'd haggle with somebody and you had to have, I mean, I must've had a three or $4 million budget at Cisco by the time I stopped, you know, I had money. But still, where do I spend that and on what? And the tools were expensive, a million dollars for a subscription, you know. Startup doesn't have that.
But we don't have that problem anymore. There's something you can do. There's the barrier to entry is very low today, which is great, really great. It's more an awareness that many people don't. Or in the plethora of tools.
I mean, I see five new tools announced almost every day in that big plethora of tools. tools, which ones should I actually use? You're probably going to concentrate on the ones that get your code out the fastest, right? And that isn't going to be a security tool.
But let me just say there's something wonderful like HorusSEC, Horus as in the Egyptian god HorusSEC, which can touch a lot of security tooling and automate it in your pipeline. So there's all kinds of really interesting things out there if you just look. that are available that people can avail themselves of. So it's not as hard as it used to be. And so rather than trying to justify a $50,000 server, I'm gonna instead start and say, let's just try something simple.
Host: And I like the ramp-based approach, right? That you start with something open source, low maintenance, and that sort of sets the culture and as you grow and as there is a need for a better security solution, you can always evaluate and start using another tool. And that makes life easy for. early adopters as well that you are not investing on day one to buy a very expensive software, but rather you are setting it up on your own and then using that knowledge to later evaluate and buy better security tool based on their needs. So
Brook Schoenfield: Right, well, there are freemium models too. We should mention that there's some freemium models. I think SNCC has a freemium model where there's a basic, you get some scans for nothing. Again, there's lots of ways to cut this, do something reasonable. And as you said, as the money comes in, as your business becomes successful, you can always reevaluate and say, Is it time for one of the commercial tools or do we up our subscription in SNCC or, you know, whatever?
Host: Yeah, that's also a good approach to look at it. Like you have an open source version, then you rather opt for a commercial version. So that way there is not a lot of cost in switching the tools, rather you are just upgrading an existing tool. Makes sense. And one of the things that you highlighted is there are so many tools coming up as well, right? And there is a new technology now called ChatGPT and everybody is talking about it. And Google also launched a bar to compete with ChatGPT. So now my question is,
As a security team member, can I use ChatGPT and get recommendations? And will that solve all of my application security problems?
Brook Schoenfield: Well, no, I don't think it will. And besides, so let me just tell you this. I asked ChatGPT specifically to please summarize chapters two and four of securing systems. And what it came back with was, you know, basic security information that had nothing to do with what's in those chapters. So you gotta be a little careful here.
Oh, and. When I asked it to please, you know, who is author, Brooke S.E. Schoenfield, that is me, you might notice the beard here. It came back telling me I was a woman fantasy writer who doesn't exist as far as I can tell. So I did post that hallucination. I thought that was pretty funny.
But nevertheless, you gotta be careful and have a little expertise. A lot of what you'll get from chatGPT is basically common knowledge. That's not bad. If you're a developer and you have no knowledge and you wanna get some basics, going to chat GPT and saying, what is application security and what should I do is not a bad start. And I'll just tell you, I'm a huge fan of AI assisted search. Why?
Because I don't have to pick through the URLs. The bot does it for me. And it'll point me in the right direction. Not always, but it will. And that saves me a huge amount of time.
I can say, hey, go out and tell me about this thing, and it'll go and search and trundle through the URLs and try to find the best, most related information. So that saves me a lot of time. I love it. I'm a big fan. On the other hand, you have to know what you're looking at. Let's take chat assisted coding.
I know a lot of people who are really getting a lot out of that. but they're experienced coders who can look and say, there's a mistake here, bot, fix this mistake. And I just at RSA, literally, I talked to a company where they no longer have their front end, he does no longer has a programmer for that. He said in an hour I can get it done by just, I want this feature. Now I see the code, now it's an experienced web coder. I see there's a problem, fix this problem. And in an hour, they can get not just usable code, but really good code.
But that's a process going back and forth with a very experienced programmer. If you think you're going to low code or no code and let chat GPT, remember, it's looked at all the mistakes of all those programmers too. and it doesn't know the difference between a mistake and not a mistake, right? You have to tell it.
But it might help, it might, you know, it's a good help, us be more efficient, sure. So that's the problem with the ChatGPT.
There are a lot of ethical considerations going on here that I'm going to dodge for the moment and just say, please see Mr. Hinton's Professor Hinton's critique of where we're going. He just quit Google and he published a critique. And I would suggest for everyone to read that and get involved in the ethical and questions around chat GPT. There are all AI stuff and training and whatnot. I'm going to dodge those bullets if you don't mind, because I don't think that's a place here to take that stuff up.
But I will say that We're going to have to wrestle with that stuff. But from a security perspective, sure, it might help. And especially if you know nothing. But again, when I asked, so I was writing an article, a little bit article.
And I said to write GPT, here's a subject. Please tell me about this subject. Now write me a bunch of paragraphs. I haven't used one of them because there was nothing original there. And people expect me. to say something from experience, from knowledge, right?
And I couldn't use anything it generated. It was wonderful. So if you knew nothing about that subject, asking chat GPT to tell you something would be great again. But if you're an expert and you expect it to write your next blog, I'm sorry. I don't think it's gonna happen. And if you write that blog, you're just saying the same thing everybody else.
Host: Yeah, I echo your sentiment that if you are an expert, then maybe there is not a lot of value you are getting. But if you are a beginner, let's say I go back to the startup scenario again, right? If it's a startup and you do not have security engineers, at least you can use ChatGPT to get some of the basic security setup. But at the end of the day, it is not a replacement, but rather it's a way to aid in your security efforts.
Brook Schoenfield: Sure, and again, it might be able to write some slightly more secure code or give you some ideas. And that's great. Like if you don't know how to secure JavaScript tokens, I'm sure you can get some code out of chatGPT because that's been done well many, many times, but make sure you look at it carefully to make sure it's not weak, right?
Again, so. This stuff is moving fast? Ask me this question again in three years. And I think I may have a slightly different answer. But for the moment, I think it's really important that we use this stuff and not trust it 100% because it does hallucinate.
Again, I'm not a woman fantasy writer. I have never written a novel ever. I wouldn't even know how to go about it. though I've written hundreds of thousands of words that have been published, I would not know how to go about writing a novel. I know nothing about writing novels. I love novels, but I don't write them. And so ChatGPT was completely wrong.
Host: seen similar. Right, right. No, I have seen many posts where folks say that, yeah, sometimes if chat GPT doesn't know the answer, it starts giving you incorrect responses as well. Because at the end of the day, it has looked at both the right data set and also the wrong data set because it doesn't know how to differentiate. Like you gave that example, right? If you ask for a particular code for a particular problem. it might have been trained with both the right set of responses and wrong set of responses as well right. So, getting the right response take it with a grain of salt in a way.
Brook Schoenfield: Well, or a little expertise. A little expertise doesn't hurt. But again, as you say, if you know nothing for these basic questions, what it brings is what you'd find in the beginning chapter of almost any book. And that's not bad, because it'll save you time and it'll get you started. So it's a tool. Again, it's a tool. Use it as a tool, not a savior.
At this moment, ChatGPT is not going to do AppSec for us.
Host: Yeah, totally. So yeah, that's a great way to end the security question section.
Let's get into those security practices rating. So the way it works is I'll share a security practice. And you can rate it 1 to 5. And you can add more context why you think it's a 1 or a 5.
Rating Security Practices:
So, the first practice is train employees during onboarding only so that they can help and identify and respond to potential security threats. There is no need for continuous training or table top exercises.
Brook Schoenfield: minus one. I'm going to go off the scale here. Don't do it this don't Bad form. Why? A Carnegie Mellon study studied fishing very carefully and what people do and if a topic is of interest, 67 percent, that is two-thirds of people will click.
So if we don't keep helping our, the people we're depending on, to do things the right way, if we don't keep helping them understand what they need to do and how to do it, they will fail. And you're just opening up a huge attack surface. So no, onboarding is important.
One year is probably not enough, you know, especially with things like phishing, but there are other things like acceptable use. What's okay on my machine? Is it okay for me to let my kids play? games on my machine? Is that okay? Incidental use? A lot of acceptable use policies allow incidental use.
That means usually you can have your personal email on the machine, but maybe not. So you really, we need to remind people, we need to remind them, no, don't grab that Excel sheet with all that personally identifiable information and take it on your machine and then let your kids have the run of it. Bad form.
And, you know, because the kids will explore. And, you know, that's they need their own machines. And, you know, that's not Good the sort of thing we need to remind people and help reinforce and give them exercises to work on these things.
Because some of these have skills. Yeah, no, it's a kind of a not continuous, but regular and repeated is really important. So, yeah, don't do it that way. You're just. Guaranteed to set up yourself for a problem. So let's go on to the next one.
Host: Okay, the next one is conducting periodic security audits to identify vulnerabilities, threats, weaknesses in your systems and applications.
Brook Schoenfield: Great. Let's give that a three and not because you shouldn't be a five that you shouldn't be doing it because it's not enough. Um, that's one piece of the defensive puzzle. So it's not enough, but you must do it. You must do it. So can I say five with with context? Don't just rely on that.
For one thing, you can't conduct audits often enough and they're too expensive. So you need to have a whole series, a whole testing regime of which your audit is one part. So let me give you an example.
You conduct an audit, and then there's an update to the software that was audited that contains a vulnerability. It'll be open until the next audit and the time to fix.
Yeah, now there might be some things that The only way you can find is with a manual audit, so that's important, but you want to be looking all the time in different ways. And besides, no one technique is sufficient. They complement each other.
And so that's why I gave it a three. That's an important part of your entire defensive posture, but not the whole thing.
Host: Okay, so let's go to the third one. Use a password manager to manage your strong passwords that contains a mix of like uppercase, lowercase, numbers and symbols.
Brook Schoenfield: Yes, that's a five. You must do that. But I would add, you've got to use a unique password for each place. This is very important, which then implies, well, maybe you have an elephant dying memory, but I do not.
So it implies a password manager. And don't. I would encourage people to not listen to the security pundits who say, well, there was a vulnerability found in this password manager, so never use a password manager.
For most people, you know, that isn't going to work. A, those are experts and they know how to deal and they have their own systems. A. And B, that's a bit arrogant. I'm going to be really critical here. to speak in that way.
And besides all software is going to have vulnerability. Every piece of software is going to have a vulnerability in it eventually. And there are some basic computer science that's behind that I'm not gonna go into here, catch one of my other lectures and you'll see, or come into my audit one of my classes at the university and I'll be happy to share it with you. But there's some basic, everything's gonna have a vulnerability. Is it don't use software if you don't like vulnerabilities It's, it's, that's one of our big problems.
So, um, you know, get a password manager and use separate passwords. And then we have a five, five, five, five, five. Do it, uh, do, especially for anything that is sensitive, like your financial stuff, make a really hard password, but you don't have to remember it. Keep it in your password manager and boom, there you are.
Host: Yeah, so that makes a lot of sense. And yeah, so with that, we come to the end of the episode. So thank you so much, Brooke, for joining with us and sharing your knowledge. It was lovely to speak with you and learn as part of the experience.
Brook Schoenfield: Thank you so much. I'm definitely honored and privileged to be included in your podcast. Thank you so much and you have a great day.
Host: Thank you. Thank you for your kind words. And to our viewers, thank you for watching. Hope you have learned something new. If you have any questions around security, share those at skill20.com, and we'll work with a security expert to get those questions answered. See you in our next episode. Thank you.