 I should have done the training. Oh, I see. Okay. Yeah. There's two laser pointers. Is that better? Can everyone hear me? Yes. Much better. Okay. I don't know what's going on with that, Michael. Thank you. Sorry about that. Okay. No, that's fine. All right. So essentially I was just talking to you, like any rejected from talking to you at DEF CON. So we don't even need people to listen to that. All right. So this talk is all about. All right. Let's see. Yeah. Okay. Can we move to the next slide please? And all right. So essentially I've got a brain that is always trying to consume as much as I possibly can all the time. And sometimes I just don't have the hours in the day to actually do everything that I want to do. And this is especially true. So when I go on Twitter and I'm on Twitter as the introduction said, pretty much all the time I'm pretty much addicted to it. I follow basically the cleverest people in the entire world as far as I'm concerned. And some of them drop some information about stuff that they're working on or something that they find interesting all the time. And I just put it into bookmarks because I just really can't get to it. And so I have, and I checked this out this morning, over 500 bookmarks sitting waiting for me to address them. And I have had a 10 yes today since I created the slide. So it's a huge issue. But it's a good one to have. And I think that's probably what the whole subject of this talk is all about. So to produce this talk just behind the scenes I used a piece of software called Dewey. It's a way of arranging bookmarks. I know that if you pay money to Twitter each month, you can do the same thing. I have a problem with paying money to do it to each month, especially since this Dewey program is free. I have no idea anything about the organization fall. I know my bookmarks are being looked at by some sort of weird government of some sorts or some company and they're selling it so that whenever I jump into Twitter, it advertises something that makes sense to me, which doesn't seem to be the case. But that's maybe why they're happy to do something for free. Who knows anyway. So I quickly got hold of this app so that I could arrange my bookmarks and have a look and see exactly what was available to me. And for the first time I actually jumped back into bookmarks that I started with about two or something years ago. There's actually good stuff in there. So next slide, please. So we're going to take a bit of a look through these. I've skipped some bookmarks because they just don't really make sense to the great public. And yeah, let's jump in. So this is like one of my oldest ones, February 27, 2019. So it's a good, what, two and a half years old. And yeah, it comes from Katie McCaffrey. And what they were talking about here is running an experiment where instead of using words and using track changes in words and comments and stuff, they decided to abandon word altogether and just make their documents in a way that they could store it in GitHub. So any changes that you made to documents, once you've committed those changes, you put like a change reason. And so anyone that's following up on your documents can just go through essentially the change log and see exactly what those changes were, which is an interesting way of doing things. The reason why I'm showing you these is a lot of these were just me thinking, well, how can we do things better? So as my introduction says, I'm a GRC consultant, but I also consider myself to be a GRC hacker. And so I'm always trying to see how can we hack the processes that we're doing. So instead of just accepting the fact that reports are done with word, but it's better. What can we do? What's a better way of us doing things? And this one just really appealed to me. So should you do this? Should you use word? Who knows? I'm up to you. But at least it's something that you should be thinking about, I don't know, if you want. And that's what these books are all about. It's just stuff for me to think about. And maybe you can think about it as well and get something out of it. So yeah, that's one thing. If you're looking at me for answers in this talk, I'm sorry, I don't have answers. These are all just ways of making me think and making me question. All right, next slide, please. OK, so it wouldn't be complete without a tweet from Dominic White, also known as Cinge, who's one of the smartest people that I've ever had the privilege of meeting him and I were originally from Johannesburg. So we used to kind of move around in different, sorry, in the same circles and bait and think together. And so I consider him to be one of the smartest guys that I know. And then Sholdovet, who he's quoting here, is also fits into that category. So yeah, businesses can get away with being technically bankrupt in terms of security debt because it isn't something that is measured. Yeah, I just love the idea of security debt. Again, not something that I can claim to know everything about and certainly not something I can do in a talk that's supposed to be 15 minutes long. But it's something that I like to think about the idea that if you take shortcuts when you're developing new systems or new services or anything to that effect, it's going to cost you down the line. And that's just something to think about in terms of security. And when you're working with organizations and you look at them and say, listen, surely when you're putting the solution together, patching was something that you considered. And they're like, well, no, not really. And it's like, well, okay, well, you're going to have to consider it now. And it's going to be more difficult for you to consider it now. And they're like, well, we just kind of fought the time. And it's like, well, then in that case, you're pretty much technically bankrupt. And it's not a security issue. It's a development issue. You should have done it right at the beginning. And I love that kind of concept of thinking of it in terms of debts where if you start it now and do it now, it'll be a good thing. But if you do it in the future, you're going to not only be paying the debt, but the interest on top of that. So yeah, this was an interesting tweet. Next slide, please. Okay, so this is one that I found quite interesting just basically because it quotes one of the people that I really, really like. And so Dr. Nikol Aforskren, who's basically written a book about essentially DevOps, including ways that she investigated on how companies do it successfully. She's like basically the one person that's scientifically tested where the DevOps is a good idea and come out with an idea that it is. Now I disagree with her on this one very specific point about the fact that she talks about maturity models and I think her definition of maturity models is different to mine. So essentially what she's talking about here is the idea of something like a PCI where you're not kind of working out what you should be doing based on your own environment but literally based on a set of best practices. And I actually really like PCI and I like the idea of the fact that you should use your best practices because in a lot of organization, that's really what you've got. And I probably shouldn't say best practices. I should probably say good practices because a lot of organizations, you know, that is the minimum that you should be doing is actually what they do. And so I guess I kind of agree with this that you should customize your controls for your organization but a lot of organizations don't even have the minimum. So this is something that I'd like to think about like to work out more and be able to come up with a good solution to what organizations should do. But yeah, so this is one that I thought I'll just pull out and highlight. Next slide, please. Okay, so going from a tweet about Dr. Forsgren to a tweet by Dr. Forsgren about someone else. So this is from Camille Faunier. And it's about, it says, it's the most insightful thing that you can say about metrics and measures is that people will game them. You don't have anything insightful to add to the conversation. So we know that. We know that people will try and game these things. Doesn't mean that you should just abandon them with gut feel or something. You should lean more to collecting good information. And absolutely. So I think if... Which continues this idea. So Dr. Forsgren carries on and says, metrics will be used against people because trust me, lack of metrics is also used against people. And the idea being that if you... is that metrics can be used against certain types of people. And absolutely it can. And especially when you look at AI or ML. So artificial intelligence, all machine learning which is based on the past essentially. And you'll see that a lot of them have issues. The reason why they have issues is because the source material is not great to start with. And the idea being, hang on a sec, but even though it's a bad thing, doesn't mean that we should stop there or ignore it and just go with gut feel because gut feel is probably based on the same data, the same information as it has been. So yeah, that's an issue. But we should actually work harder to get that source information better. We should work harder to understand what the stuff is that we're looking at. Don't abandon it just because it doesn't make sense to you. Work harder. And I think that's what I get out of this particular tweet. Next slide, please. Okay, this is just one that I just thought I'll throw in. So this is from Rachel Toback, who is one of the best social engineers out there and has computed many times at the social engineering village. And I just thought this was a good one because it kind of shows how if you look at things more deeply, they make a lot more sense. So if you look at the laziness of information security, we always say, listen, don't click on links in emails, which is actually not helpful advice at all. I always think of kind of a sign felt explaining that to Gary and him coming back and saying, that's what emails are for. Like literally like what half the point of an email is you send something to someone so they can click on a link and carry on their daily business. It doesn't make sense to say something that's just kind of glib, don't click on links, email. That person was compromised because what the hell were they thinking? They should have just not clicked on the link. But this takes it one step further and has a look at exactly what is going on with kind of spam emails. And what she's got here is a principle created by someone called, name I'm going to try and pronounce, Robert Cialdini. And that's a principle of persuasion. But like, okay, now we're looking at the philosophy behind emails. So not just don't click on links and emails, but hang on a sec. Is this email trying to increase the amount of urgency that I need to do? And if it is, do I need to actually be as urgent as the email says that I should? So it's like, okay, if you don't contact us within the next 24 hours, something bad's going to happen to your account. Whoa, wait a minute. Someone is trying to cause me to bypass my thinking to try and be quick and rash. Why are they doing this? What is, why is it in their best interest? Does it make sense that my banquet would give me a certain amount of time to respond to something? If not, hang on. So maybe someone's trying to con me and trying to bypass my actual way of thinking. This to me is so much better advice than don't click on links and emails. It's kind of understand why someone's doing something. Why are they talking to you in a certain way? Next slide, please. Okay, this one I'm getting close to, to break in the rules about spot language. There's no swearing in this, but it's close. So this is a risk matrix, which I thought this was quite cute. It's the Australian risk matrix. So if anyone is interested in knowing how risks work, you basically take the likelihood of something happening and you take the consequences to you, kind of times them together or add them together or times them together and you come up with a number. And that's how much risk there is in something happening. So yeah, so in Australia, you've got a chance of something that's either now, now or get set. And that's the likelihood of something happening. And then of course your consequences is lower than elizards. Don't be a suke. She'll be apples or fair dinkum or rooted. And then basically either something will be, she'll be right or fuck. So those are the different ones. Have I seen this used in business? No, actually. But I really like this, this one. And then the same chap came out with, he's actually from Britain. And he came out with the British one, which is on the next slide, please. And here's the UK ones. So yeah, so their chances are once in a blue moon, not likely on occasion, a fair chance. And then momentarily, which is like the opposite to what the US uses is momentarily. And then your consequences are triforce before who are chagged or royally leaped. And then of course, yeah, you can see the different ones there. So like biscuits or pop the kettle on. And then it gets worse. It's like bloody hell. And then like the worst possible one is like bugger. We better pop the kettle on. And so yeah, there's your risk matrix for the UK. Think in the interest of time and also because I don't know if it's technically possible. Can we skip the next slide and go on to the one after that one, please? But yeah, this one was just a bit of fun. But also I like the quote at the top there when someone sacrifices the main feature to ship on time. Yeah, a big part of DevOps. And you'll see a lot of these things are concerned with with the idea of DevOps and all of that. Because I think that our processes and is something that IT has totally skipped over in previous years. And we've done all the worst possible processes, the worst possible ways of developing things, the worst possible of everything. And manufacturing was like that. But they were like that a good 60, 70 years ago. And they've worked really, really hard to improve things, come up with all the best ways of doing things. And we totally ignored that. We just thought we were better than them. We just decided that that we'll do things in our own way. And it's a problem. And I think now we're actually starting to understand that Hang on These Guys actually spent a lot of time doing the right thing. And we can learn from them. And so I like to think that a lot of this has been has been worked out for us. And yeah, this is exactly what DevOps is all about actually. The idea that you need to ship something on time and that is the biggest, most important thing that you can do. But in reality, the whole point of it is to get a good working system. And that's what you should be working towards. So I just really liked the picture because it really doesn't make sense. But I also liked the quote that they've got at the top. Next slide, please. Yeah, this is a fun one about consulting. So it says, yeah, at GM, if you see a snake, the first thing you do is hire a consultant on snakes. And then you get a committee together on snakes. And then you discuss it for a few years. And then the most likely course of action is nothing because, you know, if the snake hasn't bit anyone yet, then probably won't be a problem. And then, so you just leave him to crawl around on the factory floor. A better way to do things is put in an environment where the first guy who sees the snake kills it. Well, not necessarily kills it. So I just really, working as someone, as a consultant for so many years, this is absolutely what I see in a lot of organization. And as a consultant, I'm not complaining because this pretty much is what puts food into my kids' mouths. Because the amount of times that I've been hired by an organization because they just didn't want to, you know, look at an issue and deal with it. They'd rather bring consultants in to tell them, hey listen, you have an issue. And then they still do nothing about it. It is crazy. I guess if you're in an organization, the best thing that you can do is, hang on, what is practical? What can we do? Let's get this thing sorted out. As opposed to, you know, let's get consultants in and then get a committee together and then put this together and blah, blah, blah. At the end of the day, are you actually solving what you set out to solve? Hopefully. And if you're not, then you probably need to take a deeper look at the work that you're actually doing. Next slide, please. Okay, this comes from, go see the dog, or so someone really smart and someone I enjoy following. This was quite an interesting one. Again, so what they said here is, Google says there are two shows. Okay, this is not even, you know, application-driven two-factor authentication. This is SMS-based two-factor authentication. 99% effective against bulk fishing. So that's pretty good figures, actually. And then 100% effective against credential stuffing. So what this is saying essentially is multi-factor authentication can help you out against people trying to attack your authentication, which is great information in the first place, but hang on a sec. It also, if you think about it, means that you're phishing emails that you're sending out and spending a lot of time doing. They're good, they're effective. I wouldn't say stop doing that, but you're aware that if you're just doing that and all you're really showing is that there's an issue, you're not really fixing it. Whereas with, you know, if you actually have multi-factor authentication, you're actually fixing the issue. So sometimes it's good to actually look practically at what there is and what you should be doing. Next slide, please. Okay, so this is just to show you an example of what there is in my bookmarks. This is just a picture of a control that absolutely can be bypassed easily, and you can see that in the practical, in the real world, which you can't really see that in IT. Sometimes we just put things in place without understanding them. The reason why I've actually bookmarked this, if you ever look at the next slide, please, is because it comes from Swift on security. If you don't follow them, you absolutely should be. They just said reply with security memes, and this whole kind of Twitter threads is absolutely packed full of lots of fun and games. And so I bookmarked it in case I ever needed to use it in a presentation, which I did, and here it is. Next slide, please. I'm running very low on time here. So we're just going to go through the next few quite quickly, and I think they all slide that we can get through quite quickly. So this is just a picture of when Kubernetes goes wrong, just lots of fun and games. I just love Kubernetes kind of visual puns. Next slide, please. This is just to show you that my bookmarks are not all just information security and process driven and very serious topics and stuff. Some of them are just quite crazy. So this is just a way of making it look like you have a head in a jar. I'm probably going to put on your desks to get the rest of the IT team to take you seriously. Next slide, please. This is actually a really interesting story which I had if I had more time I would jump into. It's just basically the whole idea of how processes are broken. If you send an email to this organization and get sent off to an email address that belongs to a person. So this is a few unsubscribed from the email list. It actually goes to a single person that works at the organization. Left the organization, some other IT team have picked it up, it goes to them. They do their research as to whether the person is supposed to be on the list or not and then that goes into an Excel spreadsheet which then gets emailed to someone else who then checks it against the database, manually sends it back, logs a call, it goes to a third person, et cetera, et cetera. It's a beautiful way of showing just how broken organizations can be. Next slide, please. This is just a document that shows that I kept because it's got a cybersecurity style guide which I think is really something good to use. Next slide, please. A recipe on how to make the best bread and I have tried it and it is the best bread. It's absolutely amazing. So next slide, please. Vendor documentation can definitely be not all that very useful and that's what the slide is showing. Next slide, please. This is just good advice. I think always be thinking about what your customer wants, what they're trying to do, how do you fit into their processes and just remember customer doesn't want to call the inch drawer, they want to call the inch hole. I think that's absolutely good and something that I consider every single time. Next slide, please. Next slide, please. Let me check if there's technical issues. Yeah, it's absolutely fine. The next couple of slides are not all that important. One thing I can leave you with, I guess, the last slide that I just had there was like even though I've got so much stuff and it's also probably good just to keep some of the rest of the slides were just basically just fun and games and I think the one thing I just wanted to let you know there is just keep a sense of humor about you. Life is always serious, especially in the industry that we're in but also you should just sometimes go outside, have fun, take a break, relax and let your mind just take a break itself. Really the kind of book that leads to questions is just a bunch of things that I found quite interesting once upon a time. I guess if there's any takeaways, besides the fact that you should always relax and take life easy from time to time but also there's a lot of good stuff on Twitter, there's a lot of smart people out there and I highly recommend that you take a look around and see and sometimes people are real people that don't only talk tech, they talk about their lives, they talk about how they do things and sometimes that can be even very useful and you can learn a lot from that. So that's pretty much the takeaways. Yeah, thank you all very much. If there are any questions or anything that you'd want to discuss further about any of my slides, please let me know. One thing I'm going to try and do is get hold of all the different tweets that I actually collected up.