CISSP Cyber Training Podcast - CISSP Training Program

CCT 134: CISSP Insights into Software Development Life Cycle (SDLC)

April 22, 2024 Shon Gerber, vCISO, CISSP, Cybersecurity Consultant and Entrepreneur
CISSP Cyber Training Podcast - CISSP Training Program
CCT 134: CISSP Insights into Software Development Life Cycle (SDLC)
Show Notes Transcript Chapter Markers

Unlock the secrets of weaving impenetrable security into the fabric of software development, as we dissect the Software Development Life Cycle and its crucial role in cybersecurity. We're not just coding; we're crafting digital fortresses that stand resilient against the onslaught of cyber threats. From the strategic implementation of least privilege to the complexity of secure code repositories, this episode is your masterclass in transforming functional software into fortified security champions.

Step into the dynamic battlefield of DevOps and security testing, where collaboration meets conflict and continuous integration is king. I share the ins and outs of various testing methodologies—each a critical piece in the puzzle of proactive defense. Discover how to navigate the treacherous waters of third-party components and API calls, ensuring your ship remains unsinkable amidst the ever-present threat of security breaches. Remember, it's not just about patching up vulnerabilities; it's about charting a course through the storm with airtight strategies.

Finally, we tackle the repercussions of weak security controls, the dire consequences for businesses skirting the edge of compliance cliffs, overlooking data protection. GDPR, HIPAA, PCI—three acronyms that should send a shiver down the spine of any company not taking cybersecurity seriously. I stress the importance of embedding security into every line of code, every policy, and every practice. Tune in and arm yourself with the knowledge to shield your organization's reputation and fortify its digital presence.

Gain access to 30 FREE CISSP Exam Questions each and every month by going to FreeCISSPQuestions.com and sign-up to join the team for Free. 

Gain access to 60 FREE CISSP Practice Questions each and every month for the next 6 months by going to FreeCISSPQuestions.com and sign-up to join the team for Free. That is 360 FREE questions to help you study and pass the CISSP Certification. Join Today!

Speaker 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, let's go. Let's go cybersecurity knowledge. All right, let's get started. Hey y'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.

Speaker 1:

I can tell you that Actually, I 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. I've 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.

Speaker 1:

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 in that with around CISSP's Domain 8. So that's the ultimate goal and we're going to be do a little bit more of a broad brush around these various security controls in the overall development ecosystem. Right, everybody uses big $10 words, and that's a $10 word, but basically it 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.

Speaker 1:

Okay, there are basically eight different aspects of this overall domain 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 a 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.

Speaker 1:

Now, this is kind of like when you go out and you build your house and if you have a home, you want to build it, like I just got done building a house a couple of years ago, and I had a lot of things that I thought about before I built that house. Well, 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 around safety. Well, that's an important thing. What are some other safety items? You think around 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.

Speaker 1:

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 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 more aspects to it, but we're just going to focus on these three Least privilege, fail-safe defaults and then defense in 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 customer's data.

Speaker 1:

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 ornery sometimes and 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 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.

Speaker 1:

So you look at it from a standpoint of your house. So, in my house, we just built a house a couple of 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.

Speaker 1:

Another part is fail-safe defaults. 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, 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.

Speaker 1:

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 let's say it's 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 least privilege. So if you do that when you're talking to your developers and you at least focus on those three things from a very broad brush, you're going to go a long way in helping protect your environment.

Speaker 1:

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, how many development organizations, don't have proper controls in place, and it makes me cringe. I'll give you an example.

Speaker 1:

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, just something like it's Sean at ABC, company XYZ, and then you have a password that says Sean and company XYZ123. 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.

Speaker 1:

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, 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, you guys, can you fix your code here, because this just isn't right. And the response I got back was it'd be too hard. I'm like are you kidding me? So, anyway, just keep yourself in tuned with that.

Speaker 1:

Now 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 secure? Well, if you're not sure what 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, your developers are putting in code in these various folders in this environment, and there's lots of different types of tools out there that can do this for you. But bottom line 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 attacks on those, so it's important that again, do not put anything in there that you would not want stolen.

Speaker 1:

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've 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.

Speaker 1:

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 all right, I got to do it, I'm going to get them secure. What am I going to get them secure?

Speaker 1:

Well, we go back to the three principles least privilege, okay, so that's one of them. You want to make sure that thing is least. You want to have fail safe 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 fail-safe default, with something that will fail-safe to the point of everything 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.

Speaker 1:

If you go into a development environment that doesn't have that, you need to really consider do you want to use it? I know GitLab. 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.

Speaker 1:

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 just briefly I 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 traps up 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. Well, 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 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. The 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 in how it works out.

Speaker 1:

Now 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've got to go step A, a1, a2, a3, a4. Once those are complete, I can go on to step B, b1, b2, b3, b4. Instead of doing that, you could actually pick I want A1, a2, b1, b3. 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 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 or am I going to move them to the backlog? So you have to decide, but the bottom line is those. You actually, then, are making progress on each of these items, so it's a really cool 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.

Speaker 1:

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 will happen 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 span 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 complete this process, and they call that DevOps. So if you have a good DevOps program, you can crank out code extremely fast. Now, with ChatGPT, it's even making it even faster, where you can really punch out the code as needed. So it's important that you think about how do you handle that in your DevOps environment.

Speaker 1:

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 that you have different ideas that are being embedded in this, so it's not just Sean's idea and development in 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 way to work through those differing opinions. So 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.

Speaker 1:

We're dealing with security testing. I want to kind of 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 CISSP, or do you want to get your CEH or maybe your CISM? That being aside, we're going to roll into security testing.

Speaker 1:

The importance of securities testing and software is that it helps you do different types of analysis. Now, there's basically four different types, but you can kind of have spinoffs 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 either a system, a computer, is actually doing the testing for you. If it's more dynamic, that's actually a little bit more of a static test. And then you have user acceptance testing, which is where you have users go in 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.

Speaker 1:

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 they.

Speaker 1:

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 CICD pipeline, or 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 CICD pipeline built, and some of the things out there right now that are the freeware options can really go a long way in helping you protect 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 percent. I'm just grabbing an arbitrary number, but it can do that. So it's pretty amazing on what can happen there.

Speaker 1:

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 what 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.

Speaker 1:

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? 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 being done on it. So that's something you want to consider. So, therefore, when you're dealing with supply chain aspects 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.

Speaker 1:

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 who 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 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, 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 from an incident occurring.

Speaker 1:

So, as an example, you have code review, secure coding practices, encryption and authentication. When you're dealing with code review, what do practices? Encryption and authentication? When you're dealing 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, 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.

Speaker 1:

Now, when you're dealing with detective controls, these are designed to identify and 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 maybe your SIM. The goal is 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 Sitecore 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.

Speaker 1:

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. 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 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.

Speaker 1:

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 webpage and you put an input field and you label your input field field one, and then you go okay, 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. Okay, 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.

Speaker 1:

Anything more than that, dump it, and so that if you don't set that up, then what ends up 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 backend of that environment. And that's what happens too. So now all I have is a web frontend, but when I put something in there that's an invalid code and then it barfs up this, whatever this is, it can tell me what kind of server is running, what version of the 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 this is where 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.

Speaker 1:

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 ejection attack. But if you don't have proper configurations on your system, then you can set yourself up for a lot of problems. Sometimes, 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 and 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.

Speaker 1:

The one thing I want to talk to you about, though, is 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. Experian's 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 was Equifax, not Experian Equifax, and so your Walmart 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 one bit, don't care, don't bother me 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.

Speaker 1:

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 just 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 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 up some big money very quickly. So there's a financial hits with those.

Speaker 1:

And then, lastly, 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, you know, throws out Nazism or whatever, all just bad stuff 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 going to talk about the importance of security controls in compliance and overall best practices.

Speaker 1:

Now, security controls and compliance the main thing around this is that when you put software development out there and you have a development side, we talked about legal issues 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 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 going to 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.

Speaker 1:

Now we talk about due diligence a lot. That's a big word, due diligence. 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 going to be an 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.

Speaker 1:

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 want to 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. How do they have any sort of shared passwords they have to use?

Speaker 1:

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 want to 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.

Speaker 1:

So that's security by design. You're designing it that way. Is it going through a CICD 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.

Speaker 1:

I say that knowing full well that nobody's a hundred percent. 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 want to 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 going to get eaten first. So you just have to run faster than your best somewhat best friend, right? Same concept in web development. You just got to 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 the Star Wars, and they're basically C-3PO or not OB-1, 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 the hackers come knocking, there's really not much that they can get to, or they really want to deal with it because it'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 security by design.

Speaker 1:

Now you want to also understand how do you implement these controls in the ecosystem? You need to understand do you have regular audits? Do you have security testing in place? So one thing is you got to have a policy, security policy. Two, you need to have some audits or an assessment. That's done. I'll give you an example.

Speaker 1:

I talked to some acquaintances of mine and they have a business and they asked me a question about 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.

Speaker 1:

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.

Speaker 1:

Now we kind of rolled through this. It's more of an overview approach to it, but we've talked about a lot of things that you're going to be dealing with with the CISSP. 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 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 security policy 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.

Speaker 1:

All right, that is all I have for today. Go to CISSP 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 CISSP. 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 CISSP exam. All right, have a wonderful day. No-transcript.

CISSP Cyber Training
Security Controls and Software Development Methods
Importance of DevOps and Security Testing
Software Development Security Best Practices
Importance of Security Controls & Compliance
CISSP Cyber Training Blueprint Success