CCT 046: Cybersecurity and Secure Software Design (CISSP Domain 8.1)

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerber and I'm your host for this action-packed, informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. All right, let's get started. Hey all, it's Sean Gerber with CISSP Cyber Training, and I hope you all are doing wonderful today. It's a beautiful day Actually, i'm in Europe as I record this podcast, but it's a beautiful day. Here. I can tell you that I actually had the great opportunity of going and seeing the Gerber family farm in Switzerland. Yes, it was pretty doggone cool. I enjoyed that a lot. Been wanting to see it since I was a kid and it's not in the most easy place to find, so therefore, it's one of those kind of bucket list items that you hope you can go do, and I was very blessed that I could actually go do that today. So that was awesome. But, that being said, you are not here for me to be talking about a trip to a farm in Switzerland. As cool as that is, at least for me, you are not here to listen to that. So what are we going to talk about today? Well, today we're going to be talking about SDLC and actually we're going to talk about software development lifecycle and the whole process of in that, in that with around CISSP's domain eight. So that's the ultimate goal And we're going to be getting into some of the aspects around developers and what should they do. Now, typically, we'll try to do a deep dive into one key area, but today we're going to kind of do a little bit more of a broad brush around these various up security controls in the overall development ecosystem. Right, everybody uses big $10 words and that's a $10 word but basically means fishbowl. Right, it's an ecosystem but it's a big fishbowl. So, as we're talking about security controls, what are all of those? How do they work And what's the purpose of them? That is what we're going to chat about today. Okay, there are basically eight different aspects of this overall domain we're going to that. We can delve deeper into, but I'm going to kind of quickly go over a couple of the key ones Now of the eight that are there. We've got secure design principles, we've got security controls, we've got software development, different methods, security testing, secure coding practices, risk analysis and mitigation and then supply chain security And, as you guys all know, each of those are very valuable, especially as it relates to dealing with development And, as we talk about throughout this podcast, when you're dealing, things have changed so much in the overall development space that you, as a CISSP candidate someone that's wanting to get your CISSP done potentially move on up into management or whatever role you're looking for you're going to need to understand the development world And at least some key concepts one, to pass the CISSP, but also two, to be the expert in your profession. And so this isn't just about passing the test. It's a great thing we talk about here at CISSP cyber training is the fact that you're going to help you pass the test. That is the first and utmost important thing that we're doing. However, we also have the information that's provided to you is going to help you in your career, expand it so that you can be a better security person, whatever role that is for your company. So let's just kind of roll into a couple of those right now. So, the secure design principles I'm going to give you just kind of some ideas of why we talk about secure design principles. Now. This is kind of like when you go out and you build your house. If you have a home, you want to build it like I just got done building a house a couple years ago And I had a lot of things that I thought about before I built that house. But one of the aspects you can do is think about safety, right? So if you've got railings for your stairs, you have maybe railings around, if you have a pool, whatever that might be, you think of Brown safety. Well, that's an important thing. What are some other safety items? You've got alarms, you've got locks, you've got all of those, maybe cameras. All of those things are built into your home to help make it more secure. Well, when you're developing your software, you want to also do the same type of scenario is you want to be able to build in there something that you can then turn around and help protect your data. So, whether it's protecting the application if you're developing it, or it's protecting the overall logs that are that are being generated from this, you want to be able to protect those specific items. And what are some of those ways to protect it? Well, there's basically three different ways. Now there's there's more aspects to it, but we're just going to focus on these three least privilege, fail, safe defaults and then defense and depth. Now, if you focus on this for you have a development team comes in and you kind of keep those bigger strategic buckets in place and you focus on those what you're going to get is you're actually going to help really make your application or your software, whatever that. However you're doing it whether it's API calls, whether it's maybe potentially some sort of development work that you're doing in AWS or Azure, or it's no kidding a full up program that you're building If you keep at least those three things in place and you think about those when you're doing your development, you're going to take it a long ways to protecting you and your customers data. So let's just kind of break down the least privileged part. We've talked about this in the podcast multiple times. But the ultimate goal is like if you think about your house okay, my kids, i have to, they get on, or sometimes I have to take doors off. But short of that, you may have certain parts of your house you don't want people to go into for whatever reason. Right, you may have this awesome stereo room that you don't want your two year old to go into. So if you don't want to do that, then what's going to end up happening is you're going to have to figure out what can you put in place to make to make that happen and how to actually deal with that. So let's focus on least privilege. Now, this really is. We've talked about this in this podcast numerous times, but what is it? Well, it's, the principle is exactly just how it sounds. Exactly how it sounds. So you look at it from a standpoint of your house. So, in my house, we just built a house a couple years ago and you have various security mechanisms that you put in place within your home, and these various security mechanisms that you put in your home are there to protect you from potential bad guys or girls, right? So the ultimate point is that you put these security aspects in place for that. So what else do you do? Well, you also limit people to gain access to your environment. What does that actually mean? Well, so let's say, for instance, you have this super gaming room in your house and you don't want your two year old in it. Well, you probably lock it up, maybe put an alarm on it. I don't know what you do, but the ultimate goal is. You try to say that you can't have access to all the parts of my house. So therefore, that's the least privilege. It's limiting what you can and can't do based on the actual privileges you have. Another part is fail safety faults. Now, what exactly are fail safe defaults? So, basically it comes down to is that only the authorized person should be able to open it, but what does that mean? It means you're typically your doors. Let's say you're using a school analogy your doors in your school are locked, however, the janitor has a key to all the doors, but the kids don't have keys to the doors. Hopefully, right. So the point, though, is that that is the fail safe default. The default is it is locked. The default is that only certain people are allowed access, and so, therefore, you must ensure that when you're doing your development work, because you want to limit exposure, and then defense in depth is ensuring that you have something multiple layers between you and the outside world. So say, for example, a hacker gets into your development and it says on the web, you want to have the ability so that there are roadblocks in the way of that individual from leveraging, potentially, your inputs, your passwords, whatever those might be. You want to put that defense in depth to limit that exposure. And or if they get in let's say hypothetically they get into your environment then they can't pivot and move around, they just basically end up in a dead end location. So that's the ultimate goal is you want to have defense in depth, fail safe, defaults and lease privilege. So if you do that when you're talking to your developers and you least focus on those three things from a very broad brush, you're going to go a long way in helping protect your environment. Now, another one to consider about is security controls in the development environment. Is how do you handle those? Why would you put those in your development world? And it may seem counterintuitive, right, you might be going well, that just makes sense in today's world. You put security controls everywhere, but you'd be surprised at how many people that development organizations don't have proper controls in place, and it makes me cringe. I'll give you an example. When you go to a website and it's one that potentially has financial information in it, and they will give you a username that has your name in it, along with the name of the company And just something like it's Sean at ABC dot or ABC company XYZ. And then you have a password that says Sean and company XYZ, 123. And it's basically a copy, right? So it's a super simple password And this is financial data. So then you sit there and go well, i'm going to change my password to something more complex because they give me this cheap, easy one. They just do that to make life easy on themselves, So let's go and change it and make it hard for the bad guys or girls. Well, what happens is then the developers don't have they have bad input limitations on those fields And on the storage of the databases. Where they go, they will only allow maybe certain special characters, maybe no special characters. They may have just letters and numbers, and you're just like are you kidding me? Or they have the input field is only to maximum of 12 characters. So that is where you have to have this built into this overall process And you need to make sure that, as you're building this out and you develop it, you definitely keep in mind those security controls and how you want to utilize them within your environment. Again, it's you see it all the time. I guarantee you pay attention to it And you'll start noticing it more and more And unfortunately, i had a situation where I reached out to a financial institution that we used to bank with and told them and said hey guys, can you fix your your code here, because this just isn't right? And I response I got back was it'd be too hard, am I kidding me? So, anyway, just keep yourself in tuned with that. Now, when we're also going to talk about dealing with secure code repositories now, that's a part when we're dealing with your development environment. What should you ensure is is secure. Well, if you're, if you're not sure what is a code repository is, if you're listening to this, you may go. Well, it sounds like someplace you put things and you're exactly right. You consider it like a shared folder in a group project where you have lots of folders. You have this big project and then you put stuff in these various folders. The only difference is is you're putting in code that your developers are putting in code in these various folders in this environment, and there's there's lots of different, different types of tools out there that can do this for you, but bottom line is is that it's a code repository to store data. Now, if you haven't noticed on the various security blogs that are out there, there's been some recent hacks on those. So it's important that again, do not put anything in there that you would not want stolen. Now, i say that because people don't want their stuff stolen, but if you put it in these code repositories and if you share it, so you have issues with these, right? If you just keep it to you and you put the controls just for you and you then make it secure just for you, you really limited who can gain access. But these work really well when you share them with lots of developers so that everybody can collaborate. And we'll talk about the different types of frameworks that we go through agile, waterfall and so forth. But bottom line is, you want to share this with people so that everybody can be part of the overall process, But when you do that, you now are incurring potentially more and more risk. So you need to keep in mind securing the repositories is an important factor. The other part is that you want to control access to these, so you're securing these things you're thinking about. Are I got to do it? I got him, i'm going to get him secure. What am I going to get him secure? Well, we go back to the three principles leaves privilege, okay. So that's one of them. You want to make sure that thing is least. You want to have failsafe defaults for a configuration standpoint and then you want to have defense in depth with your repository. So the point of it is is that you then have to look at your accounts that allow access. How do you provision those accounts? what kind of access do they have? who limits or opens up the access? What are the requirements? again, back to the point of ensuring that they are properly configured with a failsafe default was something that will failsafe to the point of if her thing is locked. Again, those are important factors you need to keep in mind when you are going out and you're looking at various development environments. If you go into a development environment that doesn't have that, you need to really consider do you want to use it? I don't get lab. There's a lot of different sharing out there and there's a lot of different code that's put out there. Be very careful with the code because in many cases the code is many, many hundreds of lines long, if not longer Thousands of lines of code. It's very easy for malicious software to be embedded in some of this as well. So obviously you need to ensure that you teach your people and understand what they need to be looking for in these development environments. So then we go into software development methods. What are some various methods that you can look at for development? Well, one is we talked to, just briefly touched on, is waterfall. Now, the waterfall method. It's a way that you can complete a part of a project in a specific order, And the purpose is, though, is that you can't move on until that part is complete, so let's just use it from a task standpoint. I have a lots of tasks in my little book that I have that I keep tabs of to do this, to do that. I have all these tasks, but sometimes I bounce around from going from the top task to the bottom task, to the middle task. I bounce around a little bit with waterfall. You can't do that. You basically start with the first task, and you cannot move on to the second task until you have completed the first one. So your your development method that you get into, you will scope that so that you ensure that you get these various tasks done. So, if you have a very large project you have to do, you will then carve that down into multiple tasks, in probably multiple segments to ensure that you get it complete. So that's the waterfall method. Again, you cannot. One example I saw online, which is actually a really good one, is if you're writing an essay, where do you do all the research? you know, where do you do the research? you do that first, right, then you put that in writing and then you do the editing. Same kind of concept with waterfall. It's very structured and how it works out. The agile method is a little bit more flexible and it allows you to break everything down into smaller parts. So instead of having you got to go step a, a one, a two, a three, a four So those are complete. I can go on to step B, b, one, b, two, b, three before, instead of doing that, you could actually pick I want a one, a two, b, one, b, three. You can pick those out, but you fit that within a very small window called a sprint. Now that sprint, the design of that is that you get something done during that sprint and the ultimate goal is that you're trying to get a chapter done or maybe a segment done of a book, if you're trying to write a book, rather than trying to get the entire thing done at one time. So it allows you to actually even feel like you're accomplishing more, because you go, okay, i have these 10 tasks, i got eight of the 10 done. Okay, so these other eight am I going to keep these are? am I going to move them to the backlog? So you have to decide what the bottom line is, those you actually then are making progress on each of these items. That's a really cool invite way of doing it. I've done both. I prefer agile, but it does. You have to have discipline, as you're related to working down that path. Now there's another aspect you look at is called DevOps. Now, devops is a combination of the words development and operations, and what does it do? It basically builds the software by bringing the team together. So, like you have multiple writers on a book, if you look at a book and you'll see it's been written by Bill Smith and Tom Cruise I don't know somebody And what'll happen is is that they team together to write that specific book. And so this is the same thing with development is that you have a team of people that are developing this application, but they may span multiple time zones, they may spam geographic locations, it could be a lot of different ways, but they basically work very closely together, using, in many cases, agile or waterfall to be to complete this process, and they call that DevOps. So if you have a good DevOps program that you can, then you can crank out code extremely fast, and that GPT it's even making it even faster where you can really punch out the code is needed. So it's an important thing to think about. How do you handle that in your DevOps environment? Now, the bottom line, though, is when you're dealing with DevOps, it's everyone's responsibility. So what do I mean by that? That means that if everybody's working on it, everyone has a part in the overall project, and so it's not just up to one person, it's up to multiple people. The positive is is that you have different ideas that are being embedded in this, so it's not just Sean's idea and development and this application. It's multiple people, and it allows to actually create a much better product. However, it does actually add some level of drama to this, because if you have differing opinions, you have to have a play to work through those differing opinions. So it is it's an important factor in when you're looking at do you want to set up a full DevOps environment or do you not, and I've seen it happen both ways, where if you get this working well, they can just crank out gobs of code. If it does not go well, then you get a lot of finger pointing and it can go south very quickly. So just something to keep in mind. We're dealing with security testing. I want to kind of touch I'm going to touch just briefly on a few of these other ones, and we'll have more podcasts that'll delve deeper into this. The goal is that every week I hit one of the domains and then we'll delve a little bit deeper here another actually eight weeks on the rest of domain eight or some more of domain eight. However, i've got a next one. I think the next podcast is actually going to be talking about certifications and what are the ones that you want as it relates to getting your CISP, or do you want to get your CEH or maybe your CISM? That being aside, we're going to roll into security testing. The importance of securities testing and software is is that it helps you do different types of analysis. There's basically four different types, but you can kind of have spin offs of these. You have static and dynamic analysis, you have fuzz testing and then you have penetration testing Now. I used to do penetration testing for the military. That's fun, it's awesome, but it's very laser like, focused on a specific environment, a specific area. When you're dealing with static and dynamic testing now you're actually using the. Either a system, a computer, is actually doing the testing for you. If it's more dynamic, that's more actually more, a little bit more of a static test. And then you have user acceptance testing, which is where you have users going and test around with it. That's a very dynamic environment, so you may have that. Or you have fuzz testing, where you're just basically trying to break the system. You break your application. Those are different types of security testing that you can do for your development team And I would recommend that you talk to your development team. On which ones? do they? have any of them ever worked on any of those? And then what I would recommend is, if you find people that have worked in these areas, that have done some of this testing, let them become the leader of that testing environment, because user expertise for one, but it also gives them ownership. They got security, secure coding practices. Again, you want to ensure that if you. I ran into this problem with some of my developers at one point where I asked them to come up with a secure development life cycle. How are they going to do it? And the one thing is that if you have you write your code and you get your application done, how are you verifying there's no vulnerabilities with it? So that is one of the big factors that they're trying to accomplish is that you got to go through and figure out are there vulnerabilities, are there holes in the system? What does that potentially look like as well? So you want to have that process developed in ahead of time And if you can put them in what we call a CI CD pipeline, where the pipeline, when you put the code in it, will run tests against that, it will look for vulnerabilities immediately in the code, which is a huge thing, because now you don't have to try to go and compare. Okay, well, this vulnerability says this, the robot is doing it for you. So it's a really important piece. I would highly recommend that, if you have a development team, you get some level of a CI CD pipeline built. It doesn't there, and some of those things out there right now that are the freeware options can really go a long way in helping you protect your, your applications and your development. But it's not obviously going to take you to the 100 percentile, but they can go to the point of it's 60, 70% I'm just grabbing an arbitrary number, but it can do that. So it's pretty amazing on what what can happen there. Another part is determining the risk analysis and the mitigation that goes with that. You need to consider how do you deal with those potential security risks? How do you develop the software You look at, how are the various strategies you can look at from how you can mitigate those issues, and so it's a bigger picture than what you currently are dealing with. When it comes to most, companies don't look at that. They really don't understand the overall risk analysis behind it. They just get the application done, they get it out there and they get it going. Another piece is supply chain security. This is where you have the different pieces that help everything run from a software development standpoint. So if you have third party components, as an example, you have API calls that are being reached out to a third party and there's data coming in from those API calls and that data is coming into your environment. Is it protected? Are you putting things in place that are going to help mitigate that risk with that API call Are you? did you set up a gateway specifically so that when that API call comes in that you didn't develop, they developed it, that it actually has some level of inspection being done on it. So that's something you want to consider So that, therefore, when you're dealing with supply chain aspects you have to in today's world you have to consider everything. You cannot just consider what you build in your little world. You have to determine what are all the connections into your world and what are the different applications that may be critical to the operation of your business. So when you're understanding security controls that's kind of the next section we're going to get into is what are security controls in software development? So when you're looking at various security controls that you're trying to consider, you want to have those that need to have safeguards or countermeasures that are designed to avoid, counteract or minimize security risks related to the overall development that you have in place. So you may have that set up so that. So one area that you can need security controls from a software development standpoint it will go to the easy one is your username and password. Do you have good, proper usernames and passwords that are configured. How are those usernames and passwords updated? Do you require multi-factor authentication? If you do require multi-factor authentication, do you have an out of band solution such as like, let's say, ping ID you know that kind of application Or do you just rely on, like, text messages as your out of band aspect? So you got to decide. Do you have that in place? Now? the other types of security controls are out there. You have preventative, detective and corrective controls. Now, preventative control measures designs is measured and designed to protect the from an incident occurring. So, as an example, you have code review, secure coding practices, encryption and authentication. When you deal with code review, what do you have done? You typically want to have somebody else do your code review. As you're walking through the various code, you have someone else looking at it, another set of eyes, because I know when I write a paper on something, i will make mistakes in there. Even if I proof it a couple of times, i will still make mistakes. That is why having another person look at your code is so important, because and now they have robots that will do that for you. So between doing a chat, gpt giving you good code, robots that will look at your code, potentially having another employee that you work with, one of your team members, look at your code. There's no reason that you should be putting out insecure code. Now I mean that in the fact that even any code you put out there can be insecure at any given time, however blatantly and you see it now blatant insecure code can occur and we want to avoid that at all costs. Now, when you're dealing with detective controls, these are designed to identify an alert when an incident occurs Intrusion detection systems, logging and monitoring systems. They could be Lambda functions. When maybe something comes in that is out of what you anticipate, a log file is created which then sends off to your maybe your SIM. The goal is those. Those are detective controls to help you alert when something that is out of the ordinary occurs. Corrective controls these are the things that measure and mitigate damage once an incident has been detected. So you have your patches, your backups, automatic shutdown. All of those are things that you would potentially put in place. Patching is a really good example. I've had developers who create a. They have an application that is out there. We use site cores as an example, because my team had that at one point. Don't have it anymore, but had it at one point. Really good platform does an awesome job in development. However, updates were not done that frequently on that system, so we had to go through a huge endeavor to get those systems updated because they weren't a priority. Well, by doing that keeping them updated and in tolerance, basically, then, you now are putting in place corrective controls that will help mitigate the risk and help you reduce your overall exposure. So now let's talk about some threats that you may experience within the software development world. Now, these are just a couple that we're just going to go through. There's many, many more, but these are just a few that I've got. One is an injection attack. Now, this is one that is. I used it in a previous life and you see it time and time again, but basically, what ends up happening is you inject into software stuff. Right, it could be JavaScript, it could be a command, but the reason is that it's very poorly validated inputs with your input fields, and so, therefore, it allows these programs to run, and you don't want that to happen. That's not what they were intended to do. But when you go and you set up a web page and you put an input field and you label your input field field one, and then you go, OK, drop, drag, whatever it is, it's in place, good, and it may label it name. But most cases that's all they do. They don't go back and validate that. Ok, well, name has to have a minimum of 10 characters, or minimum of three characters, bob, right, so you have three characters with a maximum of 26. Anything more than that, dump it. And so that if you don't set that up, then what is it happening is you could end up just putting all kinds of scripting language in there. You could allow it to run scripts for you. You also don't want those things to happen And therefore you could have it. One of the things we used to do is we'd put data in it and we would wait for the system to basically barf up some information about the back end of that environment. And that's what happens too. So now I have all I have is a web front end, but when I put something in there that's an invalid code and then it barfs up this, this, whatever this is, it can tell me what kind of server is running, what version of server is running. So now I know how to exploit that server. It may tell me a database that it's connected to. All of those things can happen just because of injection attacks, broken authentication. So if you have your session that we've talked about in podcasts, where you connect can be intercepted, and if you intercept the session now, they can impersonate a legitimate user. Another part of security misconfigurations this is a huge one, big monster And because it's a little bit taps into the first one with an injection attack. But if you don't have proper configurations on your system then you can set yourself up for a lot of problems. As default settings, people just allow the default setting to be there and run. If you look at pretty much most wireless firewalls especially if they were circa 2000 to like 2015, the username password is admin, admin or something similar to that nature. So if you leave the default settings as they are, well, everybody knows what the default is. So then now people potentially could gain access to the system. Same concept If you don't change your default settings with your application, you can now set yourself up for a lot of issues. So those are just three really ones that we touched on just real quickly kind of went over The one thing I want to talk to you about those. What is the impact of doing this? So let's say, for instance, if you get hacked, how does that impact your organization? Well, in most cases, people go well. Okay, my website got hacked. That's usually not bad. Well, there's aspects that can happen from a financial standpoint and from a reputational standpoint, as well as a customer trust point of view. So, reputation you get hacked. Experience a good example of this. They got hacked, they didn't respond quickly and therefore their name was mud when they got hacked, or as it may, as Equifax, not Experian Equifax, and so your Walmart I'm not Walmart, but Target was another one where they got hacked and their reputation got hit hard. A good example, which isn't a cyber issue, is things that have been happening within various companies within the United States, where they have a point of view around gay pride, whatever, i don't care, don't bother me in one bit, but I'll tell you that when they picked that level, they came and said, reputationally, i want to support this, which is fine, they can do whatever they want. They potentially pay a price for that, and so the same thing can happen with your website If you don't do this correctly and someone comes in there and says something very terrible about you, about what you support, whatever that might be, that could be used against you and now it'll have a reputational hit and it could affect you financially. So it's important that you put in place these protections to protect your company, because it will. It'll come back and get you. Customer trust is another one. You start getting hacked, people start taking their money out of your institution financial ones. You run into the situation where, if it's a HIPAA type of event, where that data that comes from HIPAA, well you would have records that would be exposed. What ends up happening is now those records are. I think at the time that I used to look at this was about $250 a record. So now that $250 a record it adds up real quick. That goes from 500 to 1,000 to 10,000, that adds some big money very quickly. So there's a financial hits with those. And then, lastly, as you're dealing with legal liabilities and that covers the gamut from just dealing with your reputational piece of this you say someone hacks your site, puts up something that is totally against what you believe Let's just say it's throws out Nazism or whatever all just bad stuff you just put on your website. Well, you take it down. So you take a reputational hit, and now there's people that are upset about that and they turn around and they sue you. So that's a possibility too. So you have to make sure that you have to convey this to your leaders of your company how important it is that you do have a good, secure system in place, because the cascading effects can be substantial. Okay, so now we're gonna talk about the importance of security, of controls in compliance and overall best practices. Now, security, controls and compliance the main thing around this is that you do when you put software development out there and you have a development side. We talked about legal issues, right, And reputational hit, but there are regulatory requirements that you could get nailed with as well, and those could come down to GDPR. Right, you're not protecting people's information and people's rights that they have as far as their PII isn't the word and they use anymore, but it's their personal, identifiable information. You didn't do a good job protecting it. You could be liable. You have a HIPAA, which you talked about before. You could be liable. You have your payment card industry standards. That is something where, if you don't put proper protections in place, they can revoke your access to credit cards, and so now you run a situation where, if you're a business and you're trying to make money and the credit card companies go no, no, you're not doing a good job protecting our customers' data. So therefore, we're gonna yank your ability to use credit cards. That could be a substantial hit, if not take you out completely. So those are important parts, but you need to ensure that you have that done. Now we talk about due diligence a lot. That's a big word. Do diligence? Let's see. I think people just kind of rolls off their tongue and they're like I'm really smart, let's do due diligence. Bottom line is did you do your backup? Did you do the background checking that you needed to do to ensure that you are protecting it? And this comes down to one do you have a policy on how you protect customer data? Two, do you have a person who is responsible for the protecting of that customer data? Now, they could be. Do you have a privacy officer, potentially, or a privacy person that deals specifically with the compliance piece of this? They could be all one and the same people, but have you defined that? That is gonna be important factor And you need to ensure that if you don't meet compliance with these pieces and you don't do the background checks and you don't understand all that. There are fines, customer trust and then, as well as reputational hits for not following through on those things, and you can see it in the news all the time. So it's important that you do really take a long, hard look at all of this, because these things hit the social media and they go like wildfire. Now, unfortunately, sometimes they're not always true, but they still go like wildfire. So it's important that you have this in place and you're ready to deal with it. Now, best practices you need to understand that when you're dealing with security in your development environment, you want to have security by design. You really wanna understand, in the earliest stages of development do you have security built into it? What that basically means is do I have specific accounts where my developers can log in? Are those accounts shared? If they're not, they're individual, which is what you want. Do they have any sort of shared passwords they have to use? Because I'll tell you right now, there's many times when developers must share passwords. Well, if they share a password because of whatever application it is, then do they have a PAM, which is a password management tool? I can't remember what the A is for. But do they have like a password keeper that is keeping their passwords for them that you can then check in, check out? So at best practice you might think, well, i don't wanna share passwords. There are definitely times when you have to share passwords because of the application won't allow multiple accounts. There are maybe the password limitations on the overall account because the application, you can't get a newer application or it's cost prohibitive, so you may have to share accounts based on the risk. But to mitigate that risk is then you have a check in, check out policy. That would be considered a best practice. So that's security by design and you're designing it that way. Is it going through a CI CD pipeline? Do you do scanning, network scanning of your web pages from an external resource? Do you do authenticated and unauthenticated scanning? So all of those pieces, those best practices that you can incur, will help you to really reduce the risk that your site or your web environment is taken out and is hacked. I say that knowing full well that nobody's 100%. You can do all of this work. You can spend gobs of time and energy trying to get it so that it is tight and you still can get hacked, because that's just the nature of the business. So you, but the thing is, is you wanna have the old analogy of if you are in a forest and there's a bear and there's two of you okay, you and your somewhat best friend you have to decide who's gonna get eaten first. So you just have to run faster than your best somewhat best friend, right? Same concept in web development. You just gotta make sure that your stuff is tight so that when the looky loos come in trying to see what's in your network, they see nothing. Okay, like an Android, like the Star Wars, and they're basically C3PO or not Obi-Wan, saying these are not the droids you're looking for. You do not want them to see anything there, you want them to move on. Therefore, it's important that you get your systems tight so that when that Hackers come knocking there's really not much that they can get to or they really want to deal with it because there's too much work or they could get caught They'll move on, unfortunately, to the next victim. So it's important that you develop a security by design. Now you want to also understand how do you implement these controls in this ecosystem? You need to understand have. Do you have regular audits? Do you have security testing in place? So one thing is you got to have a policy, security policy. Do you need to have some audits or an assessment that's done? I'll give you an example. I talked to some acquaintances of mine and they have a business and they asked me a question about how? how do we ensure that our applications are secure? I said to them do you have an assessment strategy on how you're going to go through and look at each of these various applications? Do you do this once a year? once every three years? Do you utilize OWASP's web application foundation baseline? Do you use that or do you just ignore it? And their response was well, we've kind of just ignored it up to this point. So the thing is is then you have to decide do you want to go to the work and do that or not? I'll tell you right now if you don't put an assessment on anything externally facing, you are setting yourself up for disaster. It's just a matter of time before the bad guys find a way in and they exploit it and they take advantage of you and your business. So it's important that you have some sort of security testing and auditing in place and ready to go And you have a policy that states back to that overall testing and what you're going to do, and then you follow through and you make sure that you complete those key pieces, because if you don't complete them, yeah, it's just a piece of paper and it basically says I'm going to do this, i swear I'm going to do it, but you never really do it. So it ends up being a vulnerability. And then when you get hacked, you're like well, i have this piece of paper that says we should do it, yeah, but you didn't do it, so it doesn't really matter. Have a nice day. Here's your brown box. You're fired. Have a nice day, bye-bye. You don't want that to happen to you. So those are the key factors. Now we kind of rolled through this. It's kind of more of an overview approach to it, but it does. We've talked about a lot of things that you're going to be dealing with with the CISP. So, as you're looking at taking the test, keep in mind that is the same kind of mentality. They're asking these questions to you. So they're asking you of do you have a security policy for your web development team? I'm just throwing this out. That could be one of them Or does your web, does your security policy talk, have an auditing and assessment statement in there? How often do you do that? Is that an important part of what you do? Those are big factors you want to have detailed out and available to anybody that wants to be able to see them. All right, that is all I have for today. Go to CISP cyber training. Go, check out my blueprint. You will love it. It's awesome. It will help you, give you the exact steps you need to do to become successful and pass the CISP. The first time I didn't have that. I built it specifically for you so that you can go and go step by step by step by step, to make sure that you have everything you need. Everything's covered so that you can pass the CISP exam. All right, have a wonderful day and we'll catch you on the flip side, see you.