CCT 222: TP-Link Router Risks and Software Development Security for CISSP (D8.2)
Feb 17, 2025Unlock the secrets to fortifying your software development practices with expert insights from Shon Gerber. As we navigate the complex landscape of cybersecurity, we delve deep into the urgent risks posed by TP-Link routers, used by a staggering portion of U.S. households. Discover practical strategies for protecting your network, like firmware updates and firewall configurations, and learn how potential geopolitical threats could reshape your tech choices. This episode arms you with the knowledge to safeguard your digital ecosystem against looming threats and prepares you for possible shifts in government regulations.
Venture into the vibrant world of programming languages and development environments, tracing their evolution from archaic beginnings with BASIC and C# to today's dynamic platforms like Python and Ruby on Rails. Shon unravels the intricacies of runtime environments and libraries, emphasizing why sourcing trusted libraries is non-negotiable in preventing security breaches. For those new to programming, we demystify Integrated Development Environments (IDEs) and offer insights into why securing these tools is paramount, especially as AI makes coding more accessible than ever before.
As we wrap up, Shon guides you through best practices for securing both your development and runtime environments. From addressing vulnerabilities inherent in IDEs to ensuring robust CI/CD pipeline security, we cover it all. Learn about the pivotal role Dynamic Application Security Testing (DAST) plays and how to seamlessly integrate it within your development processes. This episode is a trove of actionable advice, aimed at equipping you with the skills and foresight needed to enhance your cybersecurity strategies and development protocols. Don’t miss this comprehensive guide to making informed decisions and fortifying your software’s security posture.
Gain exclusive access to 360 FREE CISSP Practice Questions delivered directly to your inbox! Sign up at FreeCISSPQuestions.com and receive 30 expertly crafted practice questions every 15 days for the next 6 months—completely free! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success. Join now and start your journey toward CISSP mastery today!
TRANSCRIPT
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. Alright, let's get started. Let's go cybersecurity knowledge.
Speaker 2:
All right, let's get started. Hey, I'm Sean Gerber with CISSP Cyber Training. Hope you all are having a beautifully blessed day today. Today's an exciting day. Yes, we get to talk about software development. Yeah, baby, it's gonna be fun. So we're getting into software development pieces and this is going to be identifying and applying security controls in software development ecosystems.
Speaker 2:
Yeah, that's lots of really big $10 words, so we're going to try to break that down into something a little bit more bite-sized and hopefully understandable. That's the ultimate goal of CISSP Cyber Training is get it, make it so it's a little bit more understandable as you're studying for the CISSP exam. But before we do, I want to just talk about a quick article that I saw in the news today. So this is out of Wired Magazine and it's kind of a follow-on to what we've talked about a little bit before on the podcast around TP-Link routers and the potential ban that is occurring or may be occurring within the United States related to these pieces of equipment. Now, I don't know if you all are aware, but the TP-Link router or TP-Link type equipment there's a lot of it within people's houses and different places around their country that are tied and associated with TP-Link. The article basically says there's roughly around 34%, or actually 36%, of US households have TP-Link devices in them, so that's pretty substantial. But the ultimate point of this is that it's in Wired Magazine and they talk about how the fact is that the Chinese government may have their claws into TP-Link devices and therefore the US government is determining whether or not they wish to ban these products within the United States because they're concerned that the Chinese government may have access to these various networks and, honestly, that is a really good concern. Now, I don't say this about the Chinese or whoever. Any company that manufactures this kind of equipment does have the ability to put a Trojan horse type activity or active access right into these devices, and the goal, if I was the Chinese government or somebody else, is, if you had that ability to go and embed some level of software within these devices and in the event that there's a shooting match, then you can go ahead and turn these systems off. So there is a lot of subterfuge that could be involved with these types of equipment. So it was again. It was founded in. 2008 is when it was established, but it was really. It wasn't until 2022, when the United States and China were getting into some challenges around this and the one of the big issues that came out of it was related to the ownership of the Hong Kong and the United States divisions during the pandemic and how that was moved around.
Speaker 2:
So, again, one of the big factors you want to consider is do you want to run TP-Link within your company and you want to have this kind of devices there? Now, some of the things you can do to help protect your company or your home is one is regularly update your router credentials and firmware, obviously, obviously and mitigate any potential security risk that you may see there. Now that may or may not work. If that, if whatever's here, if there is anything is embedded deeply within the firmware, it may not get rid of it, right, because if you're updating the firmware, one of the big factors around that is they're providing the updates. So they may say sure, we'll update the firmware, we just won't update this little section over here to the right. So that's something to consider that if you do update the systems, you may not get rid of it, if there is anything there at all. As well, make sure your firewall settings are set and configure those in a lockdown format. Obviously you want to put some level of monitoring on these systems so if, for some reason, data is leaving at whenever the zero hour is, you have the ability to see that and potentially stop that.
Speaker 2:
What I see happening here is, if this was a specific situation where they had these routers set up to be part of the chinese government one, they would use them for active spying. But in reality, what I would say is if they were going to go and start a war, they most likely would just kill them all at that one point in time. They would shut them all down, and that would be what I would do, because that would cause all kinds of chaos and pandemonium throughout an organization, throughout a country. If 34% of the routers all shut off Because guess what? We're probably tied pretty directly into all bits and pieces of this. So you have to make the decision whether or not you want to go and rip this out and put in a US-based type of router or piece of equipment, or if you want to just roll the dice and see what happens Again. That's all up to you. You kind of have to decide what works best for you and your company. I would say, if you were based on the fact that your whole company relies on these systems. I would recommend that if you go through and do an accurate inventory of what you have and then potentially phase these out over a period of time. I know the US government is going to be forcing that movement with many of the agencies that may have TP-Linked or type systems within their infrastructure. But just keep that in mind. If you're a business, you've got TP-Link, you may want to consider migrating off of them as time permits, when these systems become outdated and you have to replace them. Just kind of consider that when you're going forward.
Speaker 2:
Okay so let's go ahead and get started about what we're going to talk about today. Okay so, as you see, this is domain 8.8.2 and this is part of CISSP cyber training. One of the things I want to mention before we get started is that I'm going to be doing a vendor podcast. Actually, just it's tied to CISSP. It's going to be one episode we'll have on vendors and I want to try to do one of those once a month. The ultimate goal of that is I've got some feedback from folks saying you know, this is great and this is feedback I've got from mentorship, because I have various mentorship programs within the CISSP cyber training platform and one of the things I get is that I don't know what are some of the good vendors to use. Now, when I put them on the podcast, that doesn't mean that I'm saying they're the vendor you need to go use. They're ones that I see that could be valuable one from a standpoint that they are tied to the CISSP aspect You'll be able to use. What domain are these tools tied to? Related to the CISSP? But also it just kind of gets some awareness around different vendors that are out there on the market. Again, bottom line is that I don't recommend any of these vendors, that I'm saying Some of them. I may actually come out and say, yeah, I recommend them, but for the most part it's just trying to get some exposure and some knowledge around different vendors in the different spaces that are tied to the different domains of the CISSP. I said different a lot there, actually about four times. So just hang on. Okay, so we're going to get into domain eight, domain 8.2, identifying and applying security controls in software development ecosystems. So let's get started. So we're going to.
Speaker 2:
First aspect is going to be talking about programming languages. Okay, that was really didn't come off right programming languages. That was really weird. So the programming languages as you all are aware, when you're dealing with development there's all kinds of languages that are out there and it's become more and more as time has gone on. When I first started I I think it was basic and then you know that shows really how old I am but there was all just a very few subset. I think I did a little bit of programming in C sharp and that was pretty much it, and my programming languages is very, very limited. But bottom line is their languages have grown right.
Speaker 2:
So developers will use, obviously, programming languages to develop their software and more and more companies are developing software and so there's a lot more developers out there in the world and hence there's different types of development languages. Obviously Ruby, ruby on Rails, python, c++, c Sharp, you name it. C Sharp, I think, probably went away, but there's lots of different things that are out there for you to develop in. My son is in the process of working with a company that is developing a TikTok version of I think it's called Up and it looks really good, but they've got a whole herd of developers for that. My dad, or my dad, my son, other son has a moving and storage business and they deal with people moving stuff from point A to point B. Well, guess what? They have a whole herd of developers as well.
Speaker 2:
So programming languages are out there, developers are out there and you therefore, from a security standpoint, you need to really consider how do you want to protect this stuff? So when we're dealing with the different languages out there, they can be compiled in C, java, fortran are examples. Yes, you probably say Fortran, what is that? That is like really old stuff and that's when they had punch cards. But you'd be surprised there's still Fortran out there on the market and what it does is it creates an executable program and this program will run right and you can reverse engineer these different types of decompilers. And so, using decompilers to kind of reverse engineer these executables that have been created in the past One example would be as if there was I have in manufacturing space people created a executable that ran a very certain process. We had to reuse decompilers to reverse engineer how it was done so that they could turn around and redo it in a different language. So those are out there and available and in the past it used to be very hard and complex to do these things, but in today's world it's a whole lot simpler.
Speaker 2:
My son was just telling me about different types of coding that can occur, and it's basically based on AI. You just grab a piece of code, you throw it in there and it does its magic. And it's basically based on AI. You just grab a piece of code, you throw it in there and it does its magic. And that's come a long way from just in a year. So you can see where this is going to go over the next four, five, 10,. But one thing you want to consider is how do you understand security? So I think if you are a developer, you may want to start getting in, and maybe you're listening to this because of that. You want to get into the security space because developers are going to become a dime, a dozen and they're going to use AI to do it. But security and understanding security for development is probably something that will be at some point replaced by AI. But you're still going to have to understand the concepts and I think that will take you a little bit longer.
Speaker 2:
So runtime environments also. What these are is these allow for portable execution of code, and then one example of on. That is the Java virtual machine. It's a. It's a runtime environment that allows portable code to be run in a very small virtual environment. Okay, what are libraries? Okay, so libraries, these are collections of non-volatile, volatile resource uses used by the program. So I'll give you an example.
Speaker 2:
If you have Python, python in of itself right is a program that's running, but it will reach out to libraries and it will pull data in and then it will run that, and these libraries hold different types of aspects. So in Python we would use timing. There'd be a time library. There would be also different types of data that would be stored in these libraries that could be fed into the overall Python program. So they may consist of configuration, data, documentation, all different types of things. They're very reusable and they will range in size from very small to can be quite substantial in size.
Speaker 2:
Now, without the libraries, each user would have to know the entire program, which is not really useful. So the goal is that you have these libraries that are relatively static and then you have the program that you're making that is dynamic and it pulls from these static programs, these static libraries, to help your program become more volume, voluminous, voluminous, yeah, better. There you go. Is that better? Um, so there's various types of libraries. We talked about date time, os related libraries, web scraping, you name it. They're out there, and there's all kinds of ones that you can use. Many of them are already developed and done. You just have to pull them off the shelf and incorporate them within your, your python or whatever program language you are using. One thing to consider, though from a security standpoint make sure you get your libraries from trusted sources, because if I'm a bad boy or girl, what can I do? I can put stuff in the libraries and then you can pull that stuff into your program. So you want to make sure that, again, you're using libraries that are reputable but, at the same time, they can be very efficient and very useful for you.
Speaker 2:
Now, ide this is. This is Integrate Development Environment. We're going to just go into a few slides around IDE, because it can be a little bit confusing to some individuals, especially if you haven't dealt with programming. It was very confusing to me. I didn't quite understand it until I dug a little bit deeper into it, and now we have a CISSP level understanding of IDE. What does that mean? It means if I'm not a developer. That's exactly what that means. Okay, so IDE this provides developers a single environment to develop their code in. It's just like a little cocoon that these things are in. Now, the software development provides comprehensive facilities to do this right, so it consists of source code editors, automation debuggers, you name it. This is this ide environment, and it's designed to maximize the programmer's production and keep it all in-house right, so he doesn't have to go to he or she doesn't have to go to separate locations to do this. They can all do it within this one ide environment. Now it does integrate with the other similar interfaces, and the great part about this is it has some ide dedications for specific program languages, so you can have an IDE creator that is done in C++, you have an IDE creator that's done in C, sharp, so on and so forth.
Speaker 2:
Right now, the three IDE download pages most searched out there on the web are Visual Studio, eclipse in Android. Visual Studio is the Microsoft-based product. Do a lot a dozen dollar, different languages in there. It's very useful. Many, many people use it. Eclipse and Android Visual Studio is the Microsoft-based product. It does a lot of different languages in there. It's very useful. Many, many people use it. Eclipse is tied specifically around Java and C, and then Android is focused specifically around the Android platform, which is a Linux-based product. So, again, those are the IDEs.
Speaker 2:
Now, one thing around IDEs that you also need to consider is that there's a lot of importance around securing these. You want to ensure that these IDEs are set up so that you cannot do any sort of code modifications or injection attacks on them. Okay, so what are some common security risks with an IDE? So we're just going to go through a few of these. I'm just going to grab a couple off of this slide deck, but what you can do is you can go to CISSP Cyber Training and you can actually see this video, and you'll be able to. If you join CISSP Cyber Training and you get access to my content, you can have access to this specific slide itself and get it. So it's all out there at CISSP Cyber Training. But just a couple of these I'll talk about is insecure plugins and extensions. So if you buy or you end up getting extensions from a third party that will plug into your IDE, you have to again, like we talk about, you have to make sure that you're getting these from reputable sources, and it's also one of these aspects I do trust but verify. One of the big factors is that you don't know what's coming into your environment, so therefore you should be very careful around that.
Speaker 2:
Another one that's a big one that I see a lot is hard-coded credentials Developing and storing API keys, passwords or other secrets in code files within an IDE environment. I see that a lot. I also see that a lot within code repositories as well. So you really want to be careful with hard-coded credentials, especially API keys. Those things are used everywhere and I mean, if you're a hacker looking for this stuff, I'm sure you can find anything you want around API keys. Because why People API keys used right to the application programming interfaces? The goal is to use those connections back and forth. Well, probably, as you're listening to the podcast, you're going. I don't see you doing anything yet. If you watch the video, you'll see me move my hand back and forth. But the hard-coded credentials, as your APIs are connected in there. A lot of times people will just hard code those in because they don't want to have to have some sort of key management system that negotiates the transfer. So they'll put those in the place and then they'll go hey, we're good, it's running, my API is awesome, and then they forget that these credentials are there. So, again, something to kind of consider when you're dealing with that.
Speaker 2:
Access control is another one, but there's about six or seven different key security risks you need to understand around IDE. Again, go to CISSP Cyber Training. You'll be able to see it there. But those are some common risks that you run into. Weak authentication is another one. So what are some best practices around securing your IDEs right?
Speaker 2:
Hardening the IDE environment, giving well-maintained built-in security features, obviously, such as visual studio code, id idea or eclipse. Building that into it with the beginning when you're building the overall environment, in making sure that you update your plugins and secure the security vulnerabilities that are patched as as necessary, right, I would also come back and say make sure that your developers understand code and how to do best security code practices. Restrict your plugin installation. Again, only verified plugins from official marketplaces. Don't go out and grab the thing oh that looks cool, I'm going to use that. Don't let your folks do that, because that will cause you problems and then next thing you know you've got a whole big issue. So, again, make sure you're getting this from official marketplaces and removing unnecessary extensions as well.
Speaker 2:
Secure code development practices. You want to obviously use security-focused plugins, avoid hard-coded credentials and then implement security scanning, obviously through GitGuardian or TruffleHog all of those can help remove exposed credentials that are out there. So, key consideration always consider security in all the things you're doing Access controls and repository security. We talk about that. Enable MFA. You need to make sure that in your GitHub, gitlab, any of those things where you're keeping your code that you have MFA tied to it and you have role-based access set up specifically around user permissions and the roles that are going on in this overall process. You want to secure your repository connections using SSH, obviously, and personal access tokens are a big factor as well. Always lock down the access to this stuff, use trusted sources, lock it down.
Speaker 2:
You want to also build your IDEs in a configured and following the best practices related to CICD which we're going to get into in a minute, which is continuous integration, continuous delivery. You want to get into doing that around best practices for those as well. Use signed commits. So when you're committing code, you want to make sure that that commit is signed right. You also want to have, when you go over code reviews. You want to have a really good code review policy in place, and how do you deal with that with all of your folks? And then, lastly, you want to really look at your overall logs that are going on within your IDE, and this you can use different types of logging and monitoring tools out there, such as ElkStack or Splunk, to actually look for potentially unusual behavior. So, again, you want to develop all that in. I'm throwing a lot at you and this is a lot of stuff. If you have an IDE environment or a CICD pipeline, it's going to take you some time to build this, and I would recommend you building this in small steps, but it's an important factor if you rely on code and code development for your organization Runtime so runtime environment this refers to the system and the software configurations that support execution of your apps.
Speaker 2:
Right, so this includes your operating system, your libraries, any middleware that's out there or any interpreters for that runtime specifically. So the importance of security is it ensures applications run securely without vulnerabilities being exploited, and that's the ultimate goal. When these things are running in the background, you don't need to be worried that there's some sort of vulnerability tied to this, such as memory corruption, code injection, privilege escalation. You want to avoid all of those aspects as much as possible. So therefore it's imperative that you have you feel confident around your runtime and what it's doing within your environment. So again it's it's called the runtime environment. It does provide an environment where everything runs. Uh, its application memory is running in this space too, and then it also is includes the compiled and interpreted languages that are in that space. So some of the best practices to consider and a lot of these we'll see as repeats from what we talked about just in the IDE space.
Speaker 2:
But you want to have least privilege right Our back. You want to make sure your root admin is. You want to avoid running those as much as possible and again, that's no different than any sort of admin account. You want to avoid running as that as much as possible. Run your apps with the minimum necessary permissions. Don't give them too much permission, because what can happen is they will be exploited and abused.
Speaker 2:
Secure runtime dependencies and libraries. You want to have trusted repositories. I kind of mentioned this already. Whether you're dealing with anything that's coming in, make sure it's coming from a trusted source. Is it your repository or is it a third party that you're pulling this in with? Make sure you update your libraries and check for vulnerabilities. Now OWASP, o-w-a-s-p they have a dependency check that is out there that helps you understand the libraries and some of the vulnerabilities that might be associated with it. You may want to run that. There's Software Composition Analysis SCA tool. I did a little bit of stuff on a previous podcast many years ago about SCA, so help it look for vulnerable components as well.
Speaker 2:
Now you want to consider the sandboxing piece of this when you're going forward. What is a sandbox? We talked about a sandbox as a place where you can have your applications. They can run in a controlled environment and it will limit the damage of anything that may occur within this environment. So that's where you keep it in sandbox. Now, the good thing about sandbox in this case it doesn't have cats, so there's no cats doing their business in your sandbox. Don't want that. That's very bad and disgusting.
Speaker 2:
Containerization One of the things around containerization is using Docker, kubernetes, lxc and then again these help isolate the applications as well. So if you containerize these, keep them small. They can operate in these containers and then getting outside the containers can be a challenge for any sort of malware. So therefore, that helps also run in an isolated form. Virtualization, run critical apps in separate VMs for additional security. Again, all these things are great. That doesn't mean you should do that, because it may not work within your environment, but it's something to consider when you're deploying these things within your company.
Speaker 2:
Some other best practices you can consider is maybe monitor runtime behaviors for anomalies. You've got a host intrusion detection system, a HIDs right that could be in place and running. You have a runtime application, self-protection, a RASP tool. It's another thing that could be running during this time frame. So there's different types of tools that are out there and may be available for you. Secure APIs and environment variables. We talked about APIs and making sure that you have a secret management tool. Hashicorp, aws Secrets Manager they all have different secrets managers. You want to use those for API environments. Now they could be tied into your gateway, which is great. That could be an awesome aspect, but you do want to have the APIs that are your key. Management is being managed by this key management system or this gateway of some kind? Because, again, when it talks about second bullet, we don't hard code credentials. We want to avoid that in your configuration files. And then you also want to enforce encryption for all of your runtime communications, if you can do it. Again, all these things I'm recommending these are best practices. This doesn't mean you have to get there today, but you should consider this, especially if you're trying to secure up your environment and it's important to you and your company.
Speaker 2:
Apply patch management. Vulnerability management is a big factor. Many people don't do enough of it and you want to make sure that you have this, a good process, in place to deal with this. I'm working with a company right now developing out the processes, a governance process around vulnerability management. They have good practices, good processes there, but then it needs to come together in a coalesced environment. So you want to make sure that you have this done. If you don't, if you're not doing it, if you're just analyze your vulnerability management, because it's one of the easiest things you can do. It's free, but it does take thought and time to go out and do it in a proper format, in a proper way, and it does. Potentially, if you haven't done it to this point, it's going to take time for you to educate your people on how to have a good patch management process in place.
Speaker 2:
Continuous delivery and continuous integration. What is this so we're going to get into that. It's a much bigger thing than I'm just going to give you with a few slides. So I would highly recommend, if you have a development shop and you are not doing CICD and you don't have a CICD pipeline, you really want to truly look at this. Take some time, do some studying around it, try to understand the CIC pipeline and how it works. So the overall view of this is a continuous delivery.
Speaker 2:
This is a software development methodology where software is released in an automated format. Now the software changes are automatically built, tested and deployed, so that you don't have to go do it Now. In the past you'd have to have a team that would go out and they would test it, they would build it, they would test it, they would deploy it all in different formats and they still have that, obviously. But it's things that don't need to have a lot of rigor. The CICD pipeline will build it, it will test it, it will deploy it and it will look for vulnerabilities before it deploys it. So CICD pipelines are a game changer. They are in software development. They make things so much easier, so much better. However, they have challenges that go with them too, and we'll kind of get into those. They allow software change to be immediately released into production, and it can be very helpful, especially when you're dealing with a lot of changes within your company. Continuous integration this is where team members will use version control system and they'll work to have the same location, the same. They call it a branch, and the branch is where they'll do their code development, they'll do their testing, but this branch is where it will automatically then be, it'll go down this path and it will be deployed.
Speaker 2:
One of the areas that I've used in the past and I say I I don't have people that do this, and I kind of looked at it and went, oh, that's cool is AWS Code Pipeline. This is a really good tool out there, very helpful At AWS. It has it because, again, aws is built on code development and so, therefore, they have this pipeline and you can utilize it to help develop your code and get it into production in a much quicker and more secure manner. Again, it takes a little time and understanding on how to deal with it, but it's a really good tool out there. There's a lot of third parties that will also have their own sort of pipelines that you can tap into, but again, just as the only one I pulled out because I've had some limited exposure to it, basically saw people doing really cool stuff going oh, wow, that's pretty awesome. How do I do that? Oh, really cool stuff going oh, wow, that's pretty awesome. How do I do that? Oh, I'm not smart enough, but you're smarter than me. So, okay, cool, I'll watch you. Okay, that's basically it. But the ultimate goal is is use pipelines.
Speaker 2:
So some security risks that you'll see Again. You can see all this at CISSP Cyber Training. I'm just going to give you a couple of little tidbits of it. Supply chain attacks, right, so malicious code injected into the dependencies or CICD pipeline script, that would be bad. So there's various things that have happened out there. You've seen in the world solar winds, many others that are supply chain type of tax. If they were to get access to your CICD pipeline and they were to then inject malicious code into these, it could cause all kinds of chaos and pandemonium. And the thing is is if you have a CICD pipeline that's been running for a while and you don't really keep tabs on it, someone could slip something in there and then you wouldn't even know it for a period of time and it would take a lot of digging to be able to go out and discover what is actually going on. The old days, as old as I am they say slip them a Mickey. I think that's just like you spike their drink, right? So you're slipping them a Mickey in your CICD pipeline.
Speaker 2:
Insufficient access controls again another one big one, right? If you don't in your pipeline, you don't have enough access controls, then users can go in and do potentially unauthorized modifications. This is a bad thing. This can cause a lot of chaos and pandemonium within your company. I've seen this happen where they have had situations where users have had too progressive of permissions, gone in, made changes and it busts the pipeline, and then everything comes to a screeching halt. Fingers start getting pointed, gnashing of teeth yeah, it's not good. So you want to make sure that you understand your access controls as well.
Speaker 2:
And then back to the exposed secrets. Why does that keep coming up? Oh, because it happens all the time. Exposed secrets, hard coding, credentials, obviously in your pipeline. Bad idea. Now, if you use some of the vulnerability scanning tools that are out there, they will flag this in your pipeline saying, yeah, this shouldn't be there. Now you as a company may decide, you may accept the risk with some of these hard coded credentials. Just because they're hard coded does not mean you should always rip them out. I mean we highly recommend that your company, you may take the position that I'm going to accept the risk on this and we're just going to move on. So something you have to work through with your company. So some key best practices around pipelines All right.
Speaker 2:
Securing coding secrets, management Again, hashicorp, trufflehog, gitguardian all of those are really good. Having robust access controls, role-based access controls, mfa tied to your CICD platform Again, all of those things are really important to do. Digitally sign your artifacts right. So digital signatures are an important part. You know that the code that's coming in, it's been digitally signed, is authentic and therefore you feel much more confident with it being put within your environment. Enforcing security testing, such as SAS and DAST, which we'll get into just a little bit here in a minute, and then software composition analysis, which we kind of mentioned a little bit earlier, again, same thing. All these things build upon themselves themselves and if you have a good plan then and you follow the plan, you're in a much more secure environment.
Speaker 2:
Monitoring cicd pipelines for activity put them into your sim right. If you have your splunk or arc side or any of these other types of sims, put that type of data in there and have triggers based on that and then secure your infrastructure with your CICD environment. This could be within, if it's on-prem, within your overall company, or if it's out in the cloud, in AWS or Azure any of those locations. But make sure you harden it. You have plenty of things built in place and then you limit the exposure to internal folks only Don't make it public facing.
Speaker 2:
Again, when you start putting stuff out in the cloud, it's really easy to accidentally put that in where it's facing externally. Maybe you want to put it facing externally because you've got developers all over the globe. Well, if you do, you better make sure that you have a lot of really tight, role-based access controls in place and you are monitoring it like a hawk. Because, again, if there's a way in, that's a really good way of getting into your company software configuration management. What is this? So this is where you have tasks that are tracking and controlling changes in your overall software, and this can be just. It helps determine what has changed, who changed it, all of those aspects that go into controlling your, your management of your tools and of your software itself.
Speaker 2:
So secure software control management is an important factor you need to consider when you're developing any sort of software within your company. So there's best practices for software control management role based access controls oh, ding, ding, ding, ding, hearing that again. Mfa important part. Storing secrets, configuration files again, storing all of your secrets that's an important part. See, I keep bringing the same concept over and over again. Hopefully you guys will understand that. Uh, environmental variables, and storing those as well as your hardcoder credentials, automate your configuration management, such as ansible puppet chef. Now I will tell you that if you automate your scm uh, that's awesome it, it works great, it's super cool, but it can be expensive. So you better plan for that. But it works really well and it makes you much more productive, it has less employees and it can be much more secure.
Speaker 2:
When you do that, implement infrastructure as a code, as a security best practice that's an important part of this and that's going down a whole different animal right, that's where you're getting into. You have scripts that are running software processes that in the past you would actually stand up a whole server just to run this process. Well, now you can actually have the scripts running in micro environments that are then going out and doing all these functions for you, regularly auditing and compliancing. Obviously, you want to make sure that you're checking this out and I would highly recommend that you do have some level of of regular auditing or assessments of these types of systems in these places. It's an important part. There's open scap and then cloud formation guard. These will also look for misconfiguration tools or misconfigurations within your overall environment.
Speaker 2:
Code repository, security, security, all right. So, code repository we talked about GitHub, bitbucket, all of these different pieces, and we've kind of touched on a lot of this already. But it's important that you have within your code repository One, if you're using it out in the world, right, your GitHub, gitlabs, those types that you have. One, you limit who has access. Two, you have MFA or multi-factor enabled. Three, single sign-on is a good piece of this, a very good aspect, and you'd want to incorporate that if possible. And then, three, you also want to avoid any sort of use of API keys in your code repository. See it, say it because you see it all the time If you go to a code repository, guarantee that there's tons of API keys. And I can I kind of bang bang on the API piece of this Cause to me? I see it as one of the biggest gaps that companies have is they will integrate APIs and they'll have no clue that what's going in or out of these APIs. So something to consider there Security, best practices add or remove any sensitive data within a repository, and that helps one.
Speaker 2:
You have a good process of putting data in, you have a good process of pulling data out and therefore, by doing that, you will limit the amount of sensitive data stored. And these are policies and processes. So you have policies of going. You shall not go. Do this is an important part with your developers. You need to make sure you educate them, you train them on this, that they don't put secrets up there, as easy, as convenient as it is. Don't do it, because guess what If someone gains access to it? Okay, life is over. Control your access, add or remove processes as well. Those are all best practices.
Speaker 2:
When you're dealing with code repositories, you also want to have a securitymd file. Now, this is something to consider that this MD file is a configuration file that's out there and it helps you with your policy, it helps you with your configurations and it does have known gaps with possible enhancements that are out there as well. So your MD file is just like a configuration file that's set up with your security tools or your security recommendations, remote SSH and personal tokens another key factor. And then always consider security with development. Always consider security anytime you're dealing in the development world.
Speaker 2:
Okay, so quickly we're going to go into SAST and DAST. So SAST is Static Application Security Testing. Now this is where the software inspects and analyzes your code. We've kind of talked about this through your CICD pipeline. Sas will look for any vulnerabilities without executing the code itself. So it's looking for known things that will go like oh, that looks like it should not be there and it will tell you that, right, and it actually uses that voice too. But it will look for that specifically and it looks for flaws before that it goes out and actually deploys that and it's similar to static code analysis but it's focused specifically around security testing. And that's SAST static application security testing. So it's got security in the name, it's static application. Kind of helps you point you in the right direction.
Speaker 2:
Next one is dynamic application security testing, or DAST. Now this is where a procedure actively investigates running applications right and it's looking for some sort of security problem. It's more of a security forward approach to web development, so that you're getting it prepped and hardened before it actually gets deployed, sends automated alerts to appropriate teams, and then the businesses can use DAST to assist in PCI compliance as well, as it allows them to integrate with their DevSecOps. So DAST is a much more robust and I'll tell you just, though. But DAST, because it's proactive and it's security forward, it can break things. So you want to make sure that, before you turn on DAST, that you have a good process to deal with all of this. One, when it blows stuff up, how do you deal with that? But two, do you have a good process to deal with all of this? One, when it blows stuff up how do you deal with that? But two, do you have a really solid core process going forward when you're dealing with that? Dynamic application security testing. So, again, static application security testing, dynamic application security testing, security of software environments.
Speaker 2:
One thing to consider when you're dealing with any sort of security is, again, you've got to help build an environment for your people to work in, where they have the tools they need to be secure. So you want to make sure that you deploy these technical controls, which we've mentioned multiple times, within your company to protect them as well as your organization. You need to understand what can happen if your environment is compromised. Understand what can happen if your environment is compromised. Do not I repeat, do not assume that just because you had one guy put it in place that who is the expert, that it's going to be good. You need to constantly be looking at this and ensuring that it is not in an insecure manner. The moment you do that, you're going to be in a much better position. But you must know what would happen if some bad guy or girl got access to your code development environment. What would happen to your company? Key thing to consider Development security considerations.
Speaker 2:
Again, separate business development functions. Don't have them together. You need to have them in separate environments. Email document management is separate from the development. So, like your developers have an email and documentation repositories that are separate from your overall enterprise, you don't want those back and forth. I don't need my developers getting email and checking it within the development environment. Why Spear phishing? Yeah, they could go ahead and get spear phished and then life is over. It needs to be a standardized an environment that is completely separate and segregated. Utilize active directory groups and virtual machines as well. So all of those pieces are a big factor.
Speaker 2:
Consider development environments as compromised. What happens? That means you need to have a separate admin and user accounts. Don't let your developers have admin privileges without checking them in or checking them out of a password, a PAM type tool, right, some sort of locker of some kind. Incorporate multi-factor, multi-person review that's another one that's really good. Have multi-people, multi people. I think that's like the multiverse. Have multiple people look at and review the codes. Right For insight. That's where that code review process is an important part.
Speaker 2:
Now, if you can automate some of that, awesome, but you also still need to continue doing it. And then the last bullet on that is trust, but verify. You need to trust your individuals, but not necessarily their accounts, and you need to incorporate logging and monitoring at all costs in many different locations. Reduce the attack surface If you're dealing with any sort of other security applications, you need to make sure that that's limited. You need to protect the credentials and security keys, which we have talked about in numerous times during this podcast, and then assess the impact of a compromise. You need to do a risk assessment of your development environment and understand what could happen if things go south. So, again, a risk assessment is an important part and I would highly recommend that you do that within your company, especially within your development environment, once you figure this whole process out.
Speaker 2:
So, as we're dealing, okay, so that is all I have for you today. We threw a lot at you today a ton, a gob, a lot, bazillion amounts but what I want you to do is go to cissp cyber training. That's cissp cyber training. Go there and you can get access to the videos that are out. What I want you to do is go to CISSP Cyber Training. That's C-I-S-S-P Cyber Training. Go there and you can get access to the videos that are out there. You can get access to my free content. I have free CISSP questions.
Speaker 2:
You can also purchase the three different tiers. You can get a tier. That's just I want to study the CISSP and it's available to you. You can also get a tier where you can get some mentorship from me and one me and one you get all the products I get. Plus, you get a. You get hours with me and we can work, work through things such as resumes we can look at, talk about your goals and so forth. That's a mentorship piece of this. And then there's a third tier which is basically you get, bring me on and I help you with one, your cissp but two can also help you with some of your security related tools and and process and questions you may have for your company. So there's three different tiers available for you. You can check them all out.
Speaker 2:
I highly recommend the first tier, at a minimum, just because it will give you all of this content. It has a blueprint to help you through, step by step by step, on what you need to how to pass the test. It will there be there for you, step by step by step. I think I said that a few times, but it's true it will. It makes it in a very logical format, makes it easy to understand and you can get it done, no question about it. I have no doubt in my mind that if you go, follow the blueprint, you will pass the test. But again, go out to cisspcybertrainingcom check it out. Or if you need a consultant, you can go to reducecyberriskcom and check that out. That's my consultant side of the house and I'm happy to help you from there as well, either way you reach out to me, I'll take care of you. Going to happen, no big deal, all right, I hope you all have a wonderfully no-transcript.
CISSP Cyber Training Academy Program!
Are you an ambitious Cybersecurity or IT professional who wants to take your career to a whole new level by achieving the CISSP Certification?
Let CISSP Cyber Training help you pass the CISSP Test the first time!
