How to Stay On Top of Security in 2023

Security and performance are the cornerstone for every project, site, app, and component you develop. But in this ever changing landscape, it can be challenging to stay on top of fundamental best practices, while also innovating.

In this conversation, hear from top technologists on how they’re staying on top of security and performance in 2023.

Speakers: 

• Ramadass Prabhakar, SVP and Chief Technology Officer at WP Engine
• Lawrence Edmondson, CTO at Barbarian
• Sergi Isasi, VP Product, Application Performance at Cloudflare
• Tim Nash, WordPress Security Consultant at timnash.co.uk
• Jimmy Squires, CTO at space150

Transcript: 

RAMADASS: Hello, everyone. Welcome to the fourth edition of Decode. It has been wonderful to see the growth in attendees each year. Over the past couple of years, there has been a significant shift in the security landscape across the industry. We have seen regular news bulletins on security breaches and security as a topic comes frequently in discussions with customers and developers alike. So today, we have assembled a fabulous group of industry experts that are passionate about security and are here to answer our questions and share their learnings with us. So let’s start with some brief introduction to our panelists. Lawrence, over to you.

LAWRENCE EDMONDSON: Thank you so much for having us. Lawrence Edmondson here, CTO of Barbarian. Barbarian is a full service digital agency. We’re located in New York.

RAMADASS: Thank you, Lawrence. Over to you, Sergi.

SERGI ISASI: Thanks. I’m a VP of product at Cloudflare. Cloudflare, we build products that make anything our customers and partners, like WPE, connect to the internet safer and faster and I’m in San Francisco.

MODERATOR: Thank you, Sergi. And Tim, over to you.

TIM NASH: I’m a WordPress security consultant here in the UK. And I basically spend my life scaring developers.

MODERATOR: Thank you. And Jimmy.

JIMMY SQUIRES: Yeah, thank you. I’m with Space 150, also a full service digital agency out of Minneapolis and CTO there.

MODERATOR: Thank you for agreeing to be on our panel today. So I would like to kick us off with talking about something unique that you’re doing in security today within your organization, or within your teams. So maybe let’s start with Sergi.

SERGI ISASI: Yeah, I’ll play off of Tim’s intro, where he scares developers. One of the things that we’re trying to do more of at Cloudflare is to give our customers more insight on their traffic and reduce the operational burden. So historically, if you wanted to find what might be affecting your network, what might attack you might be seeing, you would deploy a WAF, you’d put it in log mode and you would then have a security analyst look at the logs and see what it detected. And there’s just a lot less resources to do that these days.

So our focus for this year is to give insights to our customers on the attacks that we see on them, even if they’re not using the product that would prevent that attack today. So they can know whether or their application is under attack, or in generally good shape. And that’s our focus for the remainder of the year, introducing all of our security products and letting our customers know what might be happening or what actually is happening on their network and whether or not they want to block it.

MODERATOR: Wonderful. That sounds actually really powerful. I’m looking forward to hearing more about that. So Tim, what about yourself?

TIM NASH: So I work with lots of different clients, both agencies, but also smaller individual websites. And I do a lot of code reviews and site reviews. And up until this year, I’ve not seen the growth in people actually caring in so much that people are quite happy to get a review and just do the work that you tell them to do. So if you give them a bunch of recommendations, they just follow through. But then if I come back to the site the next year, I’m just giving them another bunch of recommendations. So I have very much seen a shift in this last year of people actually caring enough to ask questions. And so for me, code audits have been thrown away in the big, long here line 6, 4, 2 of this file, blah, needs to be done like this.

I’ve got rid of all of that and have really started focusing on education and have realized that, to be honest, what most people want is not to be told, you must fix this line, but to be told, here’s how to fix every line that’s along there. So for me, the big change and big focus change has been towards education. And this is something that’s industry-wide. I think there’s more and more people talking about security this year than last and more and more from previous years.

MODERATOR: No, that’s wonderful. I really like that focus of shifting from giving you the fish to teaching you how to catch the fish. So that’s really–

TIM NASH: I was trying to avoid that analogy at all costs for being cliche.

MODERATOR: Thank you.

TIM NASH: just well done.

MODERATOR: All right, Jimmy.

JIMMY SQUIRES: Yeah, I think there’s so much, I decided to kind of focus in on one really specific thing to talk about to this answer. And that is really restricting your scope when you’re dealing with API tokens and access. I think the Heroku, GitHub repository breach last year was a really good reminder that you’re only in control of so many things. So when we’re working with our developers, reminding them the importance of that scoped access policy on whatever platform or system you might be working with. A lot of times, a developer really wants pretty wide open access early on in development just for ease. And sometimes those things we’re probably– all ashamed to admit– they don’t get tightened down to the level they should be before production. So starting out early really considering those security scopes.

MODERATOR: Thank you, Jimmy. And Lawrence, I know that you also work a lot with developers. So what are you all looking in that front for that?

LAWRENCE EDMONDSON: Yeah, sure. Just to kind of build on what Jimmy said, for sure, we both work in advertising. So I think we see a lot of the same challenges when you work in advertising versus working in a product environment. For us, we touch a lot of different technologies, a lot of different tech stacks. We have to be technically agnostic. So what we’re seeing is consumers are engaging in multiple ways now through mobile and social. A few years ago, desktop was the primary means of accessing sites and content. Now it’s completely flipped. It went from desktop to mobile to, now, social.

So therefore, your API layers and your application layers have to be locked down in ways that have a little bit of healthy paranoia associated with them. So what we’re seeing is the attack spectrum is growing so we’re constantly seeking new ways of getting DevOps to think like programmers so that they understand the possible ways for things to be breached. So that’s kind of what we’re doing today.

MODERATOR: Thank you for that. And you mentioned how the attack vector is increasing. And that’s something that we have here, at WP Engine, have been looking at more from how do you adopt a defense in depth mechanism. So do not trust any layer to be secure. And so how do you incorporate that into the way you code and the way you write software. So thank you for that. As you all talked about the changing trend that is happening in there, breaches that have happened in this past year. So as you look at 2023, what are some major themes or threats that you all are paying attention to? And maybe, Sergi, you can start us off. Yeah.

SERGI ISASI: Sure. And this is going to sound silly because it’s 2023 and I’m going to say the word DDOS, but it’s still a thing. And it’s really been an interesting shift in the last nine, 12 months in the DDOS world. Volumetric is not really much of a DDOS vector these days. There’s a lot less reflection. And from a threat actor’s perspective, it’s both easier to launch a DDOS because you have lots of off-the-shelf tools, right? We’re almost back to script TD days, but you also have a lot fewer compromised systems to attack. So if you’re trying to do reflection, there’s not a lot of infrastructure that’s managed by someone who may not have patched their system, so you can take one packet and turn it to 10. That’s not really much of a thing anymore.

So they’re moving to layer 7. And layer 7 is both more expensive to launch in that you need a lot of CPU to do it, but it’s also a lot more expensive to mitigate. So if you have some sort of DDOS protection system, you actually have to accept the connection, examine it and then start dropping it versus something you could drop it at a lower layer. What we found and we mitigated the largest reported Layer 7 DDOS just last month on record. The big theme on those attacks is more powerful devices.

So if you think about all of the things that we have plugged in at home these days, the processor on that device is significantly better than it was even three or four years ago. So your camera does a lot more. So it’s got a beefier CPU on it, even your routers is actually a fairly strong machine. And any compromise to those devices can allow for a big, big attack, especially since, if you compromise one, you now compromise basically all of them that are connected.

The other thing we talk a little bit about these days, but is a little more quiet is, we’ve moved from compromised hardware devices to compromised accounts on cloud services. Cloud services have effectively unlimited CPU. So if I can get access to a number of individuals or companies accounts and spin up whatever I want in that cloud system, I can then launch an extremely large attack. And that’s what we’re seeing on the record breaking attacks. So yeah, 2023, still DDOS, still a thing, but now at layer 7 versus the lower layers.

MODERATOR: Thank you. That’s scary, but also at the same time, I think it points to how do we continue to enhance our security protocols and the focus area continues to grow. I know, Lawrence, you and I had chatted in the past about AI as both a boom and a threat. I would love to hear some of your thoughts around generative AI and how you see that actually impacting the surface area of security in 2023.

LAWRENCE EDMONDSON: So I’m very excited, very bullish on AI. We are at Barbarian, but at the same time, it’s very scary. The potential of something like a chatGPT being used in malicious ways. So for instance, you could have Chat GPT comment your code. And it actually does a pretty decent job, depending on what language and how messy your code is, it does a pretty good job. So the next thing, I think, we’ll see is for Chat GPT– and this might already be underway because every day, there’s like, Chat GPT does this. Like today, I just saw that it’s able to respond in Slack and find answers in Slack.

So I think the next thing, in terms of security, in Chat GPT is having Chat GPT find exploits and actually write the code to– malicious code to really exploit the weaknesses that it finds. So we’re seeing that, especially the potential for that in memory. So memory attacks don’t leave a signature all the time. So traditional viruses and virus scanners, they work on looking for signatures of an attack. Within memory attacks, you’re attacking the application. You’re doing something like a buffer overflow. You’re looking to compromise the application at runtime. I think I think Chat GPT is actually poised to do that. And I think it’s just a matter of time until we see the first large scale ChatGPT exploit happen.

TIM NASH: How would you envision that actually happening? Because obviously ChatGPT, at its heart, is just a set of APIs requests to a server. And you’re sending over a request that says, hey, generate me some malicious code. It’s returning it back. I mean, there are plenty of people already generating malicious code. How would you then get that into to be worse than the malicious code that’s already existing?

LAWRENCE EDMONDSON: So that’s the exact thing. There’s already a large repository to learn from. So ChatGPT, what it does, it actually looks at– you have to train the model. So over time, engineers train the model to recognize when someone says this, this is actually what they mean. So understand context. So it is exactly that, but in a different way. It’s training the model to actually write code and what it actually means. And some languages are very easy. So PHP, pretty easy to write code in PHP. These interpreted languages are a lot easier. It’s a lot messier, but versus doing something in like a Java, which has to be compiled, you know what I mean?

So I think an easy way to do it would be to create a model based on chatGPT 3 that actually, you train it to actually– you get through the syntax stuff, you get through all of the basic computer science things and then you take it a step up and go, OK, these NPM packages have these exploits. Look for it and go figure out a way to actually– they have these vulnerabilities, I’m sorry, and look at a way to exploit those vulnerabilities. I guarantee it, we’re not too far off from seeing something like that happen.

MODERATOR: Thank you, Lawrence. I think it’s a very nascent area. What’s interesting in this space is just about that with AI, in general, it’s got both that balance of what you can leverage it for, whether it is to actually use these signatures to prevent and learn from it to see how you can prevent us from writing poor code or vulnerable code. And at the same time, just like we have seen that people talk about, hey, I wrote my first plug-in in five minutes with Chat GPT, I think– yeah, it’s more about does this start enabling people to create malware a little faster? But I think it’s got both aspects of it.

It’s more about how do you continue to leverage any of these tools to just get better at writing code, but writing more secure code. And I know, Tim, that’s an area of passion for you. Would you like to talk a bit more about how you see Secure Code evolving in 2023 and what you’re doing in that space?

TIM NASH: Well, I mean, in many ways Chat GPT is a good example of that. If I was thinking of an attack vector, I’ll be honest, I wasn’t thinking of it doing mass scanning, feeding it lots of things as a bad actor. I was thinking of it as the average code developer who was trying to save time and was feeding in stuff into Chat GPT and throwing it out and not necessarily fully understanding all the code that’s being written, being produced, haven’t written any tests to go with it. This is just a quick thing, it’s just a quick script, it’s all fine. It gets into production, it’s not fine and it all burns.

Now this is exactly the same as something that every developer does every single day, regardless. Chat GPT is not changing that, but it does enable it slightly more easily. It does give– there is less barriers.

SERGI ISASI: Yeah, so it’s not quite the same as copying and pasting from like Stack Overflow, which I think is what you’re referring to, Tim, which is basically all I do for code. But I think it is an increase in efficiency for sure, for both positive and negative. But I do think it allows for more subtle changes and faster exploitation of something that more of which is signature-based engine can’t really catch up to. So you really when you’re doing detection, need to have a system that says, does this look similar to something I’ve seen in the past, as opposed to directly matching something I’ve seen in the past. And that’s actually on the detection side also probably best served with ML or AI or whatever you want to call it.

We’ve learned that with automated traffic on, you know, bots basically. The best way to learn how they’re getting around signature-based detection is with ML. But you’re now moving from, I absolutely know that this is bad, to, well, it’s likely to be automated, or likely to look like a signature that I’ve seen before, but not an exact match.

MODERATOR: Wonderful. Thank you. Thanks, Sergi and Tim for that added context. So amongst our attendees, we have a lot of developers and agencies that are present here today. And a lot of folks are thinking about establishing best practices, especially as the scenarios are changing in terms of threat vectors. So what are some best practices that you would recommend when building a site, an app or a platform, or just as you’re getting started on a new project. So what are some things that people should be on the lookout for?

SERGI ISASI: So I can start that. It would be more on the operational side than the development side. I think one of the things that we preach here is, one, assume that something bad will happen. So a breach is coming, you can’t just go be surprised by it. It’s likely to happen at some point. And our key– so, one, create a run book for that. So when it does happen, know which individuals to contact and what your response will be, both from detection and response, but also communicating to your customers if it affects them. And on that end, the thing that we, I think, do very well at Cloudflare and it’s been a part of our brand and I think it served us very well is to be upfront, open and as communicative as you could possibly be about anything that happened.

The openness has been very key to reestablishing trust with customers when something does occur, whether it is a software breach or something some mistake you’ve made in terms of an incident. Hiding behind it is never the right call.

MODERATOR: Yep.

JIMMY SQUIRES: I think something else too is we’ve– now that everyone is obviously remote and especially on development teams, is actually taking the time on the start of a project to do some white-boarding and architectural planning. It’s so easy to dive right into the requirements and knocking off development stories, but spending time with your peers to challenge how could this be exploited? Run through scenarios. We do a lot of scenario planning that leads to a lot of good conversation with, how we want to shore up different portions of the application.

LAWRENCE EDMONDSON: And just on that, I don’t know if anyone knows, but MPM is actually the largest repository of shared– it’s a single largest repository of application libraries out there, but that means it also poses the greatest risk. So one thing that we’re very cognizant of when taking on a new project if we’re using NPM is making sure that we’re looking at the vulnerabilities, that we’re locking in versions that we push to prod, that before we’re doing an update, we make sure that it’s something that is compatible, but also very secure. There are no open threats because we’ve seen a lot of vulnerabilities creep through NPM. So that’s just one thing to look out for.

TIM NASH: I think we’re looping it all around.

JIMMY SQUIRES: Go ahead, Tim.

TIM NASH: I think we’re looping this all around to the idea that, really, trust is being completely broken in development cycles for years. People are just coming to realize it now. And if you’re a PHP developer working in WordPress for example, you sit there calling actions and filters, but you shouldn’t be trusting those actions and filters. Any data that’s coming in, you should be validating, you should be checking it. It should be sanitized. But when it’s coming out of the database, you still shouldn’t be trusting it.

Even though you might have put that data into the database, you shouldn’t be trusting the data that’s coming out. If we’re passing something to a third party library, be that NPM, be that composer package, or just another WordPress plugin, immediately it’s left our control, we don’t trust it again. But when it comes back in, even if we’ve checked it, we still don’t trust it. And if you go in with that mindset, as a developer, that every piece of data shouldn’t be trusted and should be isolated all the way through and you should do the security checks on it at every given point, you’ll come up with a much more secure system. You might come out with a slightly slower system. You might come across with a slightly more frustrating system, and one that needs a lot more tests to make sure that what you’re doing isn’t actually causing more problems than it’s helping.

MODERATOR: Yeah.

TIM NASH: Add complication, but you end up with a much more secure system. And for most people, that’s what they want.

LAWRENCE EDMONDSON: Yeah.

MODERATOR: Yeah. You’re absolutely right. It’s about not trusting any other piece of code that’s coming through. And to what Jimmy and Sergi talked about, it’s having a plan and from an architecture perspective, or from an operational perspective, but bringing all of that together into your overall practice, whether it’s like security secure coding mechanisms or whether having an incident playbook. So Tim, I’m very interested in hearing more from you around– you do a lot of training, you do a lot of teaching around the world. What are some common mistakes that you see as people start working on projects, or mistakes that you might have made, I’ve made a lot of them.

TIM NASH: I was going to say, I’m pretty sure I am guilty of every mistake I’m about to talk about. And the biggest one and the most simplest one is being a nice person. Most developers assume good intention. Most people assume that you’re going to use their application how you wrote their application. Now quite often, we don’t write documentation so the user has no idea how to use the application in the first place, but that’s a separate issue. A bad actor will come in and take any bug and go, that’s not a bug, for a bad actor, that’s a feature. That’s an opportunity. It’s doing something that the developer is not expecting, therefore, there’s a potential route into that.

And overall, something that you see time and time again, when you say, oh look, you’ve got a set of unit tests. Oh, great. But you’ve only tested the positive things, the result you wanted. You haven’t tested what happens if we go outside of these boundaries. You’ve just tested to make sure the thing works according to what your boss wants. So what you have really are acceptance tests, dubious acceptance tests. And then it comes back down to all the basics. As a developer, it’s backed down to this, don’t trust things. And if you’re a WordPress developer in particular, WordPress actually has some really good helper functions for doing all the sort of standard security things that we ask for people to do.

And it’s about educating and learning to use them. When I’m doing code reviews, over and over I’ll see the same problems. And if I see it once in a piece of code, I’ll see it 1,000 times in the same set of code. And it will be things like, yeah well, we just allowed any old stuff to appear on the page. We didn’t bother to check whether or not it had anything in there. Yeah, we put stuff into the database. Oh look, it might look like an SQL query, might not.

All of these sort of things are easy to fix and we’ve already given the tools to fix. And the reason we’re not fixing them is often not even that people don’t know that they should not let these things happen, it’s just we get lazy, we’re doing things quickly, we’re grabbing code from Stack Overflow, we’re getting Chat GPT to do stuff for us, we’re not checking things through. And a lot of security problems comes from this state of, I must rush. I must rush. I must rush, I’ve got to get this done. I’m moving on to the next thing, I’m moving on to the next thing.

So weirdly, for a lot of developers, actually just giving them the time and the space and saying, it’s OK to take time to actually check what you’ve done so that when it comes down– and in cases where I come into play, I’m coming back and saying, well, all of these things and the developers are looking sheepish. They’re going, yeah, we know all this. We just didn’t have time.

So hopefully, giving people more time and actually giving them the tools, which we’ve already got particularly inside WordPress. WordPress has a really brilliant set of helper functions for most common security issues you would have in a WordPress plugin or theme. So it’s just about learning those and then investing the time to actually implement them.

MODERATOR: Yeah. And I think that’s really powerful, invest the time. Most often, developers know what needs to be fixed. So giving them time. So really I like that message. And Jimmy, I know that you have brought this into your own workflow at your agency. You want to talk a bit more about the secure workflow practices that you implemented?

JIMMY SQUIRES: Yeah, absolutely. And really, it starts with just having something Sergi said is having a plan, actually having guidelines and standards for your development team to follow. I know that sounds probably very basic, but I’ve seen a lot of organizations and heard from a lot of engineers we’ve hired over the years that it didn’t exist. There wasn’t organization at the place of work that they came from.

So what we like to do is we have a standard set of guidelines, all of our new engineers need to read through that top to bottom. It’s not so heavy that it’s not consumable. We like to keep it in markdown, so it’s all in a repository. We’ll probably actually open source it at some point. There isn’t anything in there that’s really proprietary, and then we encourage everyone to contribute to it. That’s an ask to all engineers.

So even in our guidelines, poke holes in where we can add, where we can be better, continually growing that. But spending time with that, some of the basic things like OWASP, that’s a really old practice, but going through that with your application, considering those things. It’s kind of what Tim said, it’s really taking the time and being OK to take the time with that. I wanted to add one extra point back to the AI conversation. Talking with a few of our engineers last week actually had an event. That’s something that we’re using Chat GPT for is actually unit testing. Taking a function and exploring it in interesting ways, how can you leverage something like Chat GPT to write a unit test where you’re not going to be the best author of that unit test, to Tim’s point. That’s where I think where we can leverage AI a lot more in a preventative way.

LAWRENCE EDMONDSON: Yeah. What we’re doing on our side, I think checklists and having a playbook are great. We’re using automated tools such as SonarQube and really having linting in place and things like that, just to raise the quality of code with linting, but also using SonarQube to just make sure that the code is more secure, that we’re looking for vulnerabilities and things like that. I think some languages are easier than others to find exploits in, as I mentioned before, just because of the nature of the language. And also just certain frameworks where the quality of coders that are contributing to that code base typically– we typically see this with Open Source, where it’s just like– there’s a lot of Stack Overflow copy and pasting going on, versus folks that actually have studied CS and really know what they’re doing. So that’s just one thing that I’ve seen.

TIM NASH: I feel like we should point out, certainly for myself, I use Stack OverFlow pretty much every day. And so we’re all guilty of it. It’s good to rail on it, but I don’t think– I mean, I remember when I first started coding. I got a magazine and was typing out code from the magazine and hitting Enter. I can’t imagine the web really working today if we still stuck around doing that and didn’t have Stack Overflow, or similar.

Sergi: No, it’s the accelerant. And hopefully, AI is the next stage of that. But yeah, it is a fun meme.

MODERATOR: Thank you. So shifting a little bit. There’s a lot of momentum that’s happening in the industry around Headless and Headless implementations. And we’ve also seen in some of our other channels today or other sessions are talking about Headless. So when we started working with Atlas at WP Engine, we met with a lot of developers and security was always a key motivator. So how do you view security with Headless? And I know, Jimmy, this is an area where you have done some projects around it. We’d love to get your take on that.

JIMMY SQUIRES: Yeah, we do a lot of work in Headless. I think nearly all of our projects at this point probably take a Headless architecture approach. I think a couple of points I just want to make on it, as it relates to security. So I think the first is that when you’re choosing a Headless architecture, you are generally putting yourself more in the open source camp in the beginning. And there’s a lot of debate, of course, on what’s more secure, open source or closed source. I tend to fall in the camp of OSS projects are more secure by nature. So you’re picking frameworks like Next, WordPress, where you have a giant community. And that tends to lend itself to more security through just exposure.

So I think that’s one. I think the second is something like Static Generation. So a lot of websites and products that are built, you don’t need the dynamic nature of a big content management, monolithic system in a traditional sense. You can leverage something like Cloudflare and really statically generate large portions of that application, thereby reducing your footprint for vectors and exposure. So we’re huge fans of that. And then, of course, you get all the performance benefits with that as well. So those are just a couple of points that I wanted to make on Headless architecture. But many more reasons from a security standpoint that we like it. But I think those are probably two of the biggest standout areas.

TIM NASH: I would like to just sort of rail back and remind people that there is still a content management system in there at the back. And that too often do I hear, Headless is totally secure. It’s like, yeah, but that exposed WordPress instance that’s still sitting there, just because you’re not directly calling it from the website, yeah, it’s still there on admin.yoursite.com. And you’ve not– there’s a certain belief that, oh yeah, well, we’re secure now so we don’t need to worry about keeping it up to date because it’s not the website. It’s like, no, no, you still need all the stuff you were doing before and now we’ve got the other side as well.

And I mean, Headless is a great term that’s for something that has been around for a long time and it’s getting a lot of momentum, but we were doing this from before WordPress had a REST API. We were pushing out content from WordPress to things like Jekyll to get at least a static site out of it. And the original reasoning for doing that was to put it varying the WordPress system or your content management system inside your network. So you could lock it down and keep it from the big, scary web.

Now we’re getting lots of hosting companies who are providing Headless solutions. And that infrastructure is now out in the cloud again. So we’ve sort of moved the big benefit for Headless. And we’re slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it’s the only move for widespread adoption. So there’s a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can’t just rely on it being–

TIM NASH: Just because something’s got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn’t mean that everything is secure. It means that you have a different paradigm. And that’s what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that’s you’re very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What’s your recommendation?

LAWRENCE EDMONDSON: I guess I’ll start off. My recommendation would be very simple. Security should be everyone’s business. I think a lot of times, security doesn’t become a topic or consideration until there’s a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It’s 2023, we shouldn’t be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it’s something that’s not easily compromised. But that’s what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what’s exposed. Know what’s on the internet and make sure that the proper– at least aware of what’s there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi’s point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. Thank you. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody’s responsibility. Give people the time and space to actually do their jobs properly and you’ll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone’s responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.