LinkedIn Monitoring - Support for Patch and Vulnerability Management (Domain 7)

Check us out at:  https://www.cisspcybertraining.com/

Get access to 360 FREE CISSP Questions:  https://www.cisspcybertraining.com/offers/dzHKVcDB/checkout

Get access to my FREE CISSP Self-Study Essentials Videos:  https://www.cisspcybertraining.com/offers/KzBKKouv

LinkedIn may be doing more inside your browser than you ever agreed to. Shon opens with a report dubbed "BrowserGate" — a claim that LinkedIn is quietly scanning for installed Chrome extensions using hidden JavaScript, raising pointed questions about privacy, browser fingerprinting, and what platforms owe users in terms of disclosure when they're collecting device-level signals tied to real identities and professional profiles. It's a timely reminder that privacy risks don't always arrive through obvious attack vectors.

From there, the episode moves into one of the most practically important topics in the CISSP curriculum and in real security work: patch and vulnerability management, covering Domain 7.8 in depth. Patching is often treated as routine maintenance, but it's more accurately understood as a primary security control — one that continuously shrinks your attack surface across servers, endpoints, cloud services, mobile devices, and OT/ICS environments where uptime requirements and safety constraints make traditional patching approaches genuinely difficult to execute.

We also address the uncomfortable reality that not every system can be patched. Legacy environments where vendors have long since stopped shipping updates require a different strategy, and Shon walks through how compensating controls like microsegmentation and network isolation can manage residual risk when a software fix simply isn't coming.

The conversation is grounded in real consequences. The Apache Struts remote code execution vulnerability and the Equifax breach serve as concrete illustrations of what happens when patch management breaks down at scale. From there, we walk through a practical patch management lifecycle: evaluating applicability, testing in non-production environments when the risk warrants it, working through change management approvals, deploying with documented rollback plans, and confirming remediation with follow-up vulnerability scans.

You'll also come away with clear, exam-ready distinctions across several concepts that CISSP candidates need to command confidently: hotfix versus patch versus update; authenticated versus unauthenticated vulnerability scanning; CVE feeds and CVSS-based prioritization; mean time to remediate as a program health metric; and how to maintain a defensible security posture when a zero-day vulnerability has no available patch and the exposure window is open.

Subscribe for ongoing CISSP exam preparation, share this episode with a study partner working through Domain 7, and leave a review so more security professionals can find the training. And tell us in the comments — what aspect of patch and vulnerability management creates the most friction in your environment right now?

🎯 Get 360 FREE CISSP Practice Questions delivered straight to your inbox at FreeCISSPQuestions.com — targeted, exam-focused practice that builds the depth and confidence you need to pass.

Join now and start your journey toward CISSP mastery today!

TRANSCRIPT

SPEAKER_00 0:00 

Welcome to the CISSP Cyber Training Podcast. Where we provide you the training and tools you need to pass the CISSP exam first time. Hi, my name is Sean Gerber. I'm your host of this Action Pack Informative Podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cyber security knowledge. Alright, let's get started.

LinkedIn Extension Scanning Privacy Concern

Why Patching Is Core Security

Scope Across IT Cloud OT Mobile

Unpatchable Systems And Compensating Controls

Hotfix Versus Patch Versus Update

Vendor Pressure And OT Patch Reality

Apache Struts And Equifax Lesson

Patch Lifecycle Testing And Change Control

Scanning CVEs CVSS And Verification

Zero Days Legacy Systems Maintenance Windows

Reviews YouTube And Free Questions

SPEAKER_01 0:25 

Good morning everybody. It's Sean Gerber with CISSP Cyber Training and hope you all are having a beautifully blessed day today. Today is Monday. And on Mondays, what do we do? Yeah, we talk about CISSP questions and CISSP topics related specifically to the ISC Squared CISSP exam. And we've got a great plan set up for today, and we're gonna go into some great kind of concepts, concepts. But before we do, there was an article that I saw in Bleepy Computer that I thought was quite interesting. So this is an article from Bleepy Computer that is calling it BrowserGate. And it claims that LinkedIn has been quietly scanning user browsers to detect installed Chrome extensions to collect specific data. Now, what is LinkedIn accuse them doing? Well, they're injecting hidden JavaScript within their website. And this code will check whether you have thousands of the specific Chrome extensions that are installed. And then by doing this, they're probing extension files in a common way to detect specifically what extensions you may have. Now, this collected data is then linked to the specific user, i.e., me, because I've got LinkedIn, and their real identities. Now, since the LinkedIn profiles are tied to real names and jobs, this can be a bit challenging. And this is also a bit controversial. So the report claims that they can reveal sensitive personal and corporate information, such as if you're looking for a job, are there tools that your company uses, potentially personal traits that are maybe inferred from the extensions that are there? And it may allow LinkedIn specifically to possibly track which companies use the competing software, identify customers of rival products, and then potentially take action against users of certain types of third-party tools. Now, this is coming out of Bleeping Computer. I don't know how real it is, but it's very interesting in the fact that LinkedIn is one of the main sources out there for people like myself to have your online resume and to have all the things that we talk about. And we talk about this routinely within CISSP cyber training that you need to go and be able to produce something and then post it on LinkedIn to show what you're actually producing. So it's interesting how this is going to play out. Now, they had earlier versions of this script, they scanned roughly 2,000 different extensions. It's now expanded to over 6,000 extensions. So the growth is substantial and I don't think it seems to be stopping. I didn't know this existed, so it's interesting to see how how LinkedIn will respond to this. They may come back and just say, Well, that's what it is. Have a nice day. If you like using our product, then great. If you don't like using our product, then get away. Who knows how they're going to handle this? But they confirmed that LinkedIn does load a script that activity checks for extensions in their browser. They did confirm that with Bleepy Computer. So we'll see how this all plays out. So there is some privacy aspects that LinkedIn needs to be aware of. If they are doing this and they're fingerprinting people via their extensions, they need to let people know that that is exactly what's happening and what's the purpose behind it. Because again, if they're doing this surreptitiously in a way that you don't really know what's going on, it's just not good for anybody. So again, collecting data, I get it. In today's world, they're collecting data on everything and everybody. But being upfront and honest with this ahead of time is a really the first and best way to handle these situations. All right, so today's topic is gonna be domain seven, seven dot eight, implementing and supporting patch vulnerability management. So that's the key aspect we're gonna be getting into today on today's podcast and training. Uh so let's roll into what we're gonna talk about. Okay, so patching. What is up with patching? Why do we need to do it? Well, you all are firmly aware of patching and its importance within an organization, and it's critical, right? It is that not merely the maintenance task, but it's a fundamental security control designed to reduce the attack surface of an organization, right? We know we're dealing with lots of security tools. We know we're dealing with lots of products, and they all touch different aspects of an organization. But patching is a fundamental piece because if we don't update the security related to these and these systems based on patches that people provide, different companies provide, you now are potentially leaving an organization vulnerable to an attack, an attacker. So basically, look at the situation where I don't know if you all saw that. There's a a gentleman that had a um video and had an advertisement that occurred here in the United States where he would go and he had a screen on a bottom of a boat, and this boat, if you were to put it out in the water, it would start to sink because he just basically built a screen in the bottom of this boat. And then he plastered it with all kinds of just this, I don't know, this stuff to basically fill in the screen holes so that the boat would float down the river. And the point of it is it's a patch, right? You're creating something to stop the water from flowing in. And the same from it goes for security issues, you're trying to stop the attackers from getting access into your organization. Now, the reality is that security professionals, you have to operate under the assumption that all code contains flaws or bugs. Now we notice that we're dealing this now with AI. We have the ability to get a better handle on what are some of the code bugs that are out there, but at the same time, even AI will miss things. But we have to go on the assumption that people are human, people make code, and the code that they make, it can have flaws with it. So therefore, there needs to be some level of upgrades and updates to these systems based on the flaws that are found. Now, how often we see this, if it's routinely prevalent that these situations will remain dormant for years until they're discovered by researchers, explored by adversaries, or in today's world, potentially discovered by AI that's out there. So these vulnerabilities can remain out there for a long period of time. Now, this has to be a very systematic discipline in which you're doing this. A formal for a patch management process has to be implemented, and this will help ensure that updates are applied consistently and tracked, moving through the organization from a reactive firefighting to a proactive security posture. So there has to be a plan in place to deal with these updates and how they're constantly monitored, tracked, and updated. Now, if you're dealing with an organization that is being inspected or audited, you're gonna have to make sure that all of this is documented and well thought out and well planned as it relates to your organization and your overall security strategy. The scope of patch management needs to be universally applicable, right? It has to have effective programs, must cover the entire ecosystem. Now that continues from traditional servers, if you may have some of those, maybe workstations, it can be AWS, it can be your OTIT infrastructure. There has to be an entire ecosystem that is covered with the overall patch management plan. Now, OT, this is an operational technology. This includes your programmable logic controllers, your PLCs, your industrial control systems, or your ICS. These often require a specialized testing due to their role in the physical infrastructure. And we're seeing this play out, especially in what's going on with Iran. The various aspects of those manufacturing facilities all have IT infrastructure in place. And so therefore, they need to be tested and managed just like anything else. So when systems go down, you have to understand is it due to the software situation or is it due to a bomb? I mean, that's just really what it comes down to in this situation, especially when it relates to Iran. But OT technology and OT systems are incredibly important that I sometimes will say that they are overlooked in so many cases. People just assume they're going to work until they don't. And then there's a problem. Hardware and mobile, modern patching includes CPU microcode updates to include hardware level flaws as well as increasingly diverse set of mobile devices. We are seeing more and more mobile devices in everything. This even comes into the OT space as well. They are in every situation, almost in every place. And I don't know if you all saw the article around Elon Musk starting up a chip manufacturing plant in Texas. Again, this is only going to increase and grow with time. Now, the unpatchable reality is you need to understand that some legacy systems, end-of-life system software, or embedded devices may never receive an update. And I would say that that's becoming less and less a situation. In the old life that I used to have, there was definitely plenty of systems that would never receive an update. I will tell you though that you need to try your best to try to update all these systems as much as you possibly can. If there is no way to update these systems, you need to have a good plan on how to deal with that. And that comes to deal with through micro-segmentation, it can deal through different types of physical separation from the overall network. Lots of different places can have different aspects related to this that you can protect. There's in these cases, compensating controls, such as network isolation, like I said, are required. And the network isolation can be a virtual isolation or it can be potentially a physical isolation. It just really comes down to how you want to do it within your organization and what works best from a risk and from a business perspective. So, but there are systems you may end up never patching, and you're just gonna have to figure out how to work through those. So, some key concepts and potential dynamics related to this. So, while often are used interchangeably, you need to truly understand the differences between some key terms: hotfix, patches, and updates. These are all three very important terms that you're gonna have to know. Now, many of you probably already do, but let's just kind of get into this to understand with the CISSP, you need to have a different grasp of this. So the hotfix is something that's urgent, specific, that you have to accomplish immediately. Those are things that are out there that they're saying, you know what, we have a patch coming, something's on its way, but we need this to be delegated and dealt with very quickly. So therefore, we are going to send out a hot fix. Now there's a patch, which is your general bug fix that is out there. This is a patch that's been vetted, it's gone through its testing. They are now putting it out in the market and they're saying you need to go and do this. Whereas the hot fix in many cases has been tested, but not to the same level of rigor that you would with a traditional patch. Now, an update often includes new features. So maybe there is a patch that's in the update, but the update's coming out, and they go, you know what, we know that there's some issues with it. We're gonna put this update, but there's some new features that we're wanting to add to this specific set of software. So therefore, we're putting this out today. So this is to understand the differences between your hotfix, your patch, and your update. Now, vendor accountability is an important part of this. So there's market pressure, regulatory requirements, and legal liability are increasingly forcing vendors to be much more transparent about the vulnerabilities and when they will be releasing them. And this is a great thing. I mean, it's very important. I'll tell you, living in the OT space and the ICS world, there were getting updates to those systems were very few and far between. And why was that? Well, because of the legal liability that they felt if they made any sort of change, it could actually cause impact to these manufacturing facilities. So the attitude was if it ain't broke, don't fix it. Now that is changing because of the legal liability and because these systems now are targeted in a much larger and broader scale. The folks such as Emerson, such as the different types of PLC manufacturers, they are actually doing patches and updates to these systems in a much better and more granular way. Now, we're gonna throw a case study out there why patching is so important. So this is the Apache Strutch. Now, this happened back in 2017, so a long time ago, this is when this occurred. And what ended up occurring is because of this update that didn't get done in a timely manner, a lot of people ran into a lot of different issues. So the Apache Strutch issue was that web apps are often deserialized and they are converted into what they call a Java object. Now, the struts that were designed with Apache were failed to properly validate any input that's coming in. Yeah, and obviously when you're dealing with web development, you want to have some sort of input validation to occur with all apps aspects coming into an organization. Now, these attackers crafted payloads that manipulated Java objects during the processing, and this led to a remote code execution, basically running the attackers controlling the commands of what's going on in those systems. So, an important part of all of this was that their patch was out. However, it was not updated in time. There were gaps in its patching cycle, and because of that, there was companies that were compromised because once this thing hit the wild and people knew they could use it, and having remote code execution, that is an important factor. Now, I'll tell you from a previous life as a hacker that when we were working on red teams and we would be working in facilities, if I had remote code execution, it made life so much easier. Anything remote code was amazing because of the fact that I could sit home and I could do it at any point in time and I had full access to these systems. This is what took down a big chunk of Equifax. And I don't know if you remember this since 2017. Again, it's almost nine years ago. The problem that came into though is the CISO, the lot of the C-suite, all lost their jobs because of the situation. They could have updated and they could have patched the system, but they chose to delay. And because of those delays, it cost them their jobs. This is an important part, and it also cost a lot of people a lot of other stuff. I think Equifax was in the hundreds of millions of dollars in SUS that they had to deal with because of all the privacy issues, because of the vulnerability that occurred. So again, great concept, great idea of why you need to make sure your systems are patched and managed. And you need to do it also from a risk-based approach. It's an imperative part, is that just because a patch comes out, you may choose based on the risk to not do it immediately, but you may do it, have a plan to do it in the future. Now, the patch management lifecycle, you need to have an evaluation phase. Not every patch is necessary for every environment. Just kind of what I alluded to already. You need to analyze whether the patch applies to your OS and if the vulnerability it fixes is even reachable in your network. Now, some people will say, you know what, I have a separated network. It's virtually subsegregated, it's segmented off, no one's gonna touch it. Now, the thing you have to be aware of is, and I agree with you, in many cases, that may be a situation where you may not want to do an update. You say there's no reason for it. That being said, there also could be situations where you don't think people are gonna have access to it, but what happens if you have supply chain where you have individuals, maybe third parties that are logging into this system using unmanaged devices to access it? If that's the case, how do you know that someone hasn't basically piggybacked in on them as they're into your network? So it's an imperative part. You really need to understand what systems are you not going to patch and why. And then you need to document all of that. Now, rigorous testing isn't important. Never deploy a patch directly into production. And I say this a little bit with out of both sides of my mouth. You shouldn't pat put patches into your environment without proper testing. That being said, in many cases, when it comes to like the Microsoft type patches, pushing those out once they have like Patch Tuesday is a potentially good idea in the fact that now you don't have to actually have a testing plan, have to have additional people to do that. Are your Windows systems you feel confident that Microsoft is gonna take care of this in a well way? They're gonna actually be able to do this in a manner that you feel confident that if there is a problem, they're gonna roll it back. Something for you really to kind of consider. Now, now again, if you're dealing with some specific systems, this may be the right thing is for you to do testing. In some other systems, you may say, you know what, I'm just gonna roll the patch out immediately once it comes out. So you need to kind of figure that out. Now, there's an isolated non-production network is you typically used to have patches installed. And this is to understand the side effects of this specifically happening in your network. If you deploy a patch, what does it do? Does it cause your system to go down? Does it cause any sort of outage whatsoever? Understanding this on the side is an important part of what you're trying to accomplish. So having that set over and working on that specifically around your patches is an important part, but you have to have the people and the resources to be able to do that. There needs to be an approval or change management process in place as well. Once tested, patches must go through a formal approval process. This is the change management piece that they try to talk so hard about in the CISSP, is that you follow your change management process. If a patch comes in, how are you gonna manage it? This ensures that the business is aware of the deployment and that there are documented rollback plans if things go sideways. And so it's an important part for you to keep in mind that how are you gonna manage these situations if and when they do occur. So again, approval and change management, incredibly important part of you having a good process within your organization. Vulnerability scanning. You need to differentiate between authenticated scans and unauthenticated scans. So an authenticated scan is using credentials to see inside your operating system. So if you're gonna be doing a scan inside your network, is it authenticated to come in and can actually see what's going on? An unauthenticated scan is where the attacker's view is from the outside and they can't see anything whatsoever. I would highly recommend you do both, right? You have an unauthenticated scan, which will give you an idea of what the attacker can see, but you need to do authenticated scans to really truly understand what is visible from the outside if credentials were compromised. Vulnerability feeds, these are subscribing to the CVEs. This is your common vulnerabilities and exposures database. This is where it's a vendor-specific security boltins are potentially pushed. Now, are all vendor bulletins pushed there? No, but many of them that are working with the overall environment and the ecosystem will push out CVEs and they will end up saying they have a problem and they're gonna go and they need to try to fix it. And the goal is that you can go and check out your CVEs to see what your company may or may not be exposed to. But then prioritization of CVSS scores. These are the common vulnerabilities scoring systems, is designed to help you know what patches to prioritize because you may not patch everything all the time, like we've mentioned, but you may patch the critical ones down to maybe the lower level ones, you may not. So this is where the CVSS can help you. Now I'll tell you that many of your scanning tools will bake all of this into them so that it will tell you that you have a problem or you don't have a problem. You're just gonna have to figure out how to manage the issue once you deal with it. Vulnerability management lifecycle. The continuous loop of this is that it's a discover, prioritize, remediate, and verify. So this is the overall loop that you need to look at when you're trying to understand your vulnerabilities. Now, after a patch is applied, a follow-up scan is mandatory to ensure the vulnerability is actually closed and that no new issues are introduced. You need to go through this. So you do your scans, you set them up. I would highly recommend that you set your scans up on a very frequent or routine basis. Obviously, you want to do your scans in a time frame that is not going to be disruptive to your organization, such as Monday morning would be a bad time to do a scan. But maybe Sunday night, on the other hand, is a good time to do a scan. Reporting security teams must report on the mean time to remediate or MTTR to demonstrate the effectiveness of the program to your overall leadership. Metrics are an important part of everything that you do, and you need to make sure that you have these documented well within your organization. So again, vulnerability management lifecycle is an important part of this overall ecosystem of vulnerability scanning and vulnerability management. So, what are the challenges you're gonna have to deal with? We have zero day vulnerabilities that you have to struggle with, and these are what you're gonna have to figure out how do you manage these when you don't have an existing patch. So, say something hits the streets and it is showing up, it's a zero day. It's basically never been seen before and it is vulnerable to everybody, or everybody is vulnerable to it. What should you do? This is where you have to understand your overall infrastructure and have a good grasp of it so that when these situations do occur, you have a plan in place on how you're gonna manage it. If it's an externally facing website and there's a zero day, how are you gonna deal with that? If it's something inside your network, you know it's a zero day, how are you gonna manage that? Knowing that, you know what, we might be okay for a period of time, we're not too worried about it. But this is where you have to explain this information to senior leadership so that they're aware and they understand what they're actually uh signing up for. Legacy systems. Now, when a system cannot be patched, such as some medical devices or old industrial controllers, what are you going to do around this? So you need to implement compensating controls to mitigate the risk. And then you need to understand how are you going to do that. So, again, having a good strategy of knowing the assets within your organization, having the ability to go and find them, and then the ability to basically mitigate the risks that they're there is incredibly important for you and your company. Now, maintenance windows, these are the need for security with the business requirement for availability. You need to understand when you can do the patch. Now, in the manufacturing space, so often they have outage windows. Now, there's times when you can actually update these systems and Time, but there's some systems that have a specific outage window that you are the only time you can do any updates is during that window. And these manufacturing facilities are running 24 by 7. They are very rarely are they ever down, and if they do go down, it's for a very short period of time. So you have they have scheduled maintenance windows in which you will go and then they will do updates to their various systems, their various the processes, and then that is a perfect time for you to do updates and patches to the overall environment. That's what would occur during this maintenance window. So this is ensures that you have availability for those systems and you're not accidentally taking them down with the patch that you're trying to deploy. Thank you so much for joining me today. That is all we have. Hope you enjoy this. Hey, please head on over to iTunes and over wherever you get your podcast from or your video content from. And please leave a review, send me some notes, let me know how this is working for you and how your CISSP studying is going for you specifically. I am super, super excited to see how this plays out for you. So please feel free to reach out to me anytime if you have questions. Again, thank you so much for joining me at CISSP Cyber Training. Have a wonderful day, and we will catch you on the flip side. See ya. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes as I would greatly appreciate your feedback. Also, check out my videos that are on YouTube and just head to my channel at CISSP Cyber Training, and you will find a plethora or a cornucopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 360 free CISSP questions to help you in your CISSP journey. Thanks again for listening.