Sounds like you have a garbage security team. They should be able to tell you exactly what the problem is, how it could impact the business, and how to fix it.
Arguably, their value-add is negative. They're asking OP to do something that OP may need to do anyway (updates are routine), but they're asking for priority and also asking for a special report back.
Agreed. In this case and scenario, their existence can be completely replaced by firing them and giving OP access to the scanner, or at the very least, the report itself.
It sounds like the security team has the info and they are just lazy as fuck. "I've bene really busy, can you just go ahead and do a bunch of work that may or may not be needed and may not resolve the issue, just to save me the hassle of doing my own job".
Fuck those guys.
The scanning tool our security team uses automatically exports a report. All that they do is put my email address in at the beginning of rhe scan. That apparently leaves them time to suggest mitigation techniques such as firewall zones if I can't remediate a CVE right away for some reason.
I agree with what the problem is and how it can impact the business, but the security team shouldn’t be expected know how to fix it past a list of options in the CVE.
They may not need to know all of the technical details of how to fix it, but they should know what the potential fixes and workarounds are, else how can they know if a vuln has been properly fixed or mitigated? To provide an example, consider the fortigate SSLVPN vuln CVE-2024-21762 - security team flag that you have fortigate devices on a version that has this vuln - but the vuln is only exploitable if you have SSLVPN enabled - if they're unaware that one of the fixes is to disable SSLVPN they'll keep saying you need to patch to mitigate, when you are fully mitigated already.
It also doesn't sound like their security team even know which CVEs or other vulns they have, they're just saying "something is wrong" which is wholly unhelpful. IMO it's even worse than a user saying "My computer is broken, fix it" and providing you no info - because the security team do seem to have this info, they just won't share it.
Also sounds like an overworked security team, and how hard can it be to take a look at the version you are running, the latest version and what vulns are patched. You don’t need that security team for that.
What good is that if they're not giving him CVEs? Yup, something was patched...no idea if it's what they're talking about. Overworked? They're doing a scan that outputs a report. Send it to him and let him read it if they're too "busy".
If we were placing bets, I'd bet that their scanner popped something "informational" and they don't know what that means, they just want to be able to say they reduced "vulnerabilities and findings".
TLDR: They should be providing the information from the vulnerability scan.
No way, fuck that bullshit. I might buy overworked if it took them a few days but they provided the requested information.
Not all vulnerabilities have anything to do with "latest version" or "vulns patched".
For example, and speaking from experience, once upon a time a vulnerability scan revealed a VM as accessible to the outside internet when it was not supposed to be at all.
No amount of patching and updating would have addressed that. That guy just sounds like a lazy ass hat.
> how hard can it be to take a look at the version you are running, the latest version and what vulns are patched.
The latest version of *WHAT*? It sounds like the absolute most information the security team are providing is possibly which server is affected, but even a single purpose server can be running many different bits of software, each with other libraries they rely on which may or may not be obvious.
This is the exact reason we have vulnerability scanners, it's basically impossible to stay on top of every single piece of software and all of their individual libraries installed across every server in your environment. Even if you do update absolutely everything as soon as updates are available, that's no guarantee that the updates actually patch the vulns - look at the list of log4j/log4shell impacted software, and note that despite being a 3yr old vuln at this point, there are still some bits of software marked as affected (NOT fixed!), so update all you want - if the vendor hasn't patched it in their version of the library, you're still vulnerable.
I’m not sure what your security team is doing, but it isn’t proper vulnerability management. If they’re going to report a system as vulnerable, they have to provide the information as so why. Whether that be the CVE, or maybe even what they were scanning for. You can’t do the work, if you don’t know what the work to be done is.
Not to mention that updates to systems can produce backporting false positives. So, OP may be doing exactly what they need to do, and the scanner is popping a false positive based on a backport.
Ugh tenable, especially agentless, loves to do this with red hat systems (granted I know just having a version number makes it hard to figure out of its a red hat package with backported fixes and not really a 3 year old version)
>Hi, these devices are vulnerable
I would expect that to be followed by
As outlined here, here and here and this is relevant in our environment because of this this and this
The following steps need to be taken to remedy, as outlined here here and here
If I got a message saying : >Hi, these devices are vulnerabe
My response would be "ohmygosh that's terrible"
And I'd carry on with my day until such time they got a grownup to help
Create a ticket template for them for CVEs. Have it require a link to the CVE in question as well as a link to the remediation. Don't accept any remediation work from them without it.
Generate a ticket about the reported vulnerability.
Add a list of the things you need to complete the ticket:
1. What devices are affected?
2. What is the specific CVE being reported?
3. What is the level of the vulnerability?
4. What is the Risk valuation of the vulnerability? Is it a minor vuln that affects 80% of systems? Or is it something that only effects a couple off systems, but the effects would be devestating in the event of compromise?
5. Are they Enterprise Systems or Operational Tech Systems?
6. What specific application is affected?
7. What is the criticality ranking of the system/processes that are affected? (example - is it a minor system that can wait, or is it a absolutely crucial to business process server
There's about a dozen more elements you can add to the ticket questionnaire. Have a statement like "please list downtime available for scheduling to resolve this vulnerability patching" and "Work on vulnerability remediation will commence once this questionaire is completed.
Then assign the ticket to whomever reported the vulnerability for remediation, and add their team lead or manager as a watcher on the ticket.
This will punt the responsibility for data collection back in their court, and they won't be able to claim "I reported the vulnerability, but u/tdhuck didn't do it!"
My sec team created a security dashboard that contains pretty much everything I need: hosts, vulns, CVEs, and suggested fixes. I just check that daily. If something new shows in the list, I implement the fix. No communication necessary. We dropped our vulns by 80% in one month, and it continues to decline.
With a couple more steps depending on your ticketing platform, you can automate this ticketing response. For example in Service Now, or Jira, you can add a drop down option on opening a new ticket. Then its just kicking back the automated response, and you may be able to automate assigning the ticket back to the reporter and the reporting management with some other tweaks.
What's nuts is that most of that info should be a simple export from the vulnerability tool.
We even give our Infrastructure team access to our tool so they can see all the details and check if their remediation's worked(agent based scans twice a day) without waiting for us to confirm(either adhoc or every other Friday during our Vulnerability committee meeting)
Many company’s security teams interface with the end users directly. Often the security teams have elevated corporate responsibilities and can either order or request downtime windows for vulnerability mitigation as part of their enforcement scope.
> Many company’s security teams interface with the end users directly.
They do? That's news to me, tbh. The app owner should be the one interfacing with the end user and coordinating downtime. *Maybe* that's security for some apps but I really can't imagine that being the case at a company of any real size. Our security team has their hands full with their own jobs without also doing that of app support.
They don’t need to be the app owner, but they should understand how the end user uses the application in their role. It’s not enough to know what the application is, or does. You have to know how the end user interacts with it. What steps they take, what ‘tricks’ and ‘shortcut’ they may try to pull… because if the end user thinks they can speed up their own processes by side stepping your security initiatives they will.
"They don't need to be the app owner, they just need to know everything about it and everything about how people use it". idk man that sounds a lot like an app owner.
I didn't say you need to know everything about it. I said you need to know specifically how the end user is using it. I'm passing on solid gold sage advice here.
If the scanner is any good, it should have a plugin output or similar which describes proof of the vuln. Where I work, if this is missing then we assign the ticket back to the analyst that made it.
Quite frankly, the vuln world has a lot of dead weight in it. You aren't asking for them to move mountains, it is just a checkbox in the export wizard. Tell these people to nut up or shut up. "something happened somewhere" is the type of description that is written by people who have zero intention of making a contribution and you don't need to give them the time of day.
Its such a shame that it became wider knowledge that IT sec pays well. Now all the morons who would have studied economics 10 years ago are piling in and plague technical people with BS like this.
The only reason you may need a security person in terms of CVEs is for them to tell you if/what kind of problem it is and how to remediate it.
Even just getting the CVE number should be completely automated by any decent tool.
In my experience, a lot of security guys don’t understand security. They only know how to drive the gui of a particular tool, and often not that well.
I once had a whole big thing with our team when qualys flagged some DLL as being vulnerable and out of date. Problem was, the vulnerability only affected the Korean language version, which would never apply to our server.
They just couldn’t understand.
This would need to be escalated. I didn’t see anything wrong on your part, it’s whomever you’re working with. If you have a ticketing system, have them create a ticket and force them to enter in the needed information. “I’m sorry I didn’t grab that information” is not acceptable.
Just tell them their scanner is wrong, because it's producing CVEs that are invalid. Nobody should be able to get away with garbage requests like this. Have them escalate to nexpose or whoever else they're using.
Unfortunately, infosec often is able to get away with such stupidity because everyone in the upper management is afraid of them. They should be submitting these sorts of requests through a standardized ticketing system, just like everyone else. And the tickets should be closed if they don't provide critical and/or requested information-just like with everyone else.
Any company that has a dedicated infosec team better have a ticketing system, and there damn well better be formal processes for this. Reject with prejudice, and copy management in until they have a process.
Long ago when i used to care I'd have tried to pull info out ot them what the issue is make sure it's fixed...
Later when I cared less I'd hound them for a ticket, but still try to patch stuff
Now I'm approaching a point where I don't respond to bullshit emails, they know we have a ticketing system, they can use it or not.
Now... I'll still patch things, on a as short schedule as is reasonable, automatically if possible. If I know of real vulns I can't patch I'll apply mitigations.
But unless my boss asks I'm not responding to lazy morons. Or if it's a client, still trying to learn to forward it to a PM and forget about it.
Wow, and i thought our security team has quirks :D At least they gave ALL IT read-only access to scanning tool (Qualys). So anyone in our IT teams can go and check themselves and not wait until some burning reports come through to top management (some still do). And it provides not only a list of CVEs,. but also detected bits (registry/files) and usually supposed fix (e.g. version x fixes this issue). Your sec team is either insanely gatekeeping and afraid if they show what they have, someone will think they are not even necessary. Or they don't understand what scanner shows or how to get the info you are asking for (looking at some top level dashboard with hostnames and numbers of vulnerabilities only). And i am not sure which one is worse..
This security team could be doing more harm than good. Over my nearly 30 years in IT, I've seen any number of systems taken down by running patches/fixes that "fixed" things that weren't broken/vulnerable. This security team has no business asking you to patch if they won't provide the relevant CVE(s).
The absolute worst is garbage scanners and security staff that don't understand the concept of backporting. "Hi, SSH is vulnerable on this server due to CVE-XXX-XXXX."
"We run EL, which has backported a patch for this in version x.y.z-123. Here's the changelog, as well as the exact revision we are running."
"Hi, the scanner still says the version is vulnerable. Please fix it."
People love to hate on documentation but this is what happens when policy and governance isn’t created. Ideally you’d consult the vulnerability management policy and have a defined point to call out that the vulnerability management team is missing. Even better would be a RACI chart.
This sounds like a Manager or Director should become involved in this. Our Manager simply had us return those Tasks lacking information back into the Security Team's queue and he walked over and had a discussion with the CSO. Done in 10 minutes.
That said, the Security dude is not exactly wrong about blindly updating firmware. We were inundated with security vulnerability tasks several years ago. I finally went over the top in the last few years. Aggressive windows patching, really aggressive 3rd party application patching, all devices (docks, laptops, printers) get latest firmware forced. Just a super over the top blasting of every known update. It worked, our security tasks are down to a trickle. When they quit getting hits on workstations and servers they started scanning printers, which are now all updated and even have new SNMP community names. We barely ever get tickets now and it's usually just a couple of crap devices that are out of diskspace or something like that.
Here is another trick, when they do send you a good task with all the information and it lists only 10 affected assets then go setup automation to find the systems that security did not find on their scan. If there are 10 in the task there are probably another 15 in the environment that are also vulnerable. Setup logical automation to find them and leave it running.
Yeah, you have a leadership issue, not a technical issue. This is what a manager or director is hired to perform. You are in need of changing another IT sister team's process, that's clearly not in your pay grade. Delegate this straight to your manager. This is plainly in the wheelhouse of managerial work.
Meanwhile, separately from this, go nuts upgrading everything. It's not a waste of time to be two steps ahead of Security team. Run Dell Command Update on your workstations, run HP WebJetAdmin on the printers. Don't do this manually, setup repeatable automation and just let it bake in the oven and churn while you work on other things. Then you never get the security task in the first place. Become proactive instead of reactive. All of my workstations are on the latest BIOS, they have the latest drivers for the month, they are all on the same OS and same feature update and the same monthly patch. All my printers have current firmware. All my docks are updated. All my 3rd party apps(filezilla, chrome, notepad++, Java, etc..) are updated. Security is not knocking on my door anymore because I have leapfrogged them.
Uh, ok, just forward each ticket you get to the Help Desk since those are the guys that update software revisions. That's how 99% of the vulnerabilities are fixed, the rest might be some post-update registry change. If they are not giving you that information, then you escalate up the chain of command. You seem to have an opportunity here to just slough this work off to another group, take it. Why are they sending to you if you are not even the responsible party?
Honestly there is a micro-fine line between software and firmware in this day and age. It's just a command we run that installs an update. Most people are just panicked about the reboot.
"Why should we update this?"
answer: "don't care, it's available, let's roll it"
I update windows every month "blindly", I don't sit back and wait for the ransomware to hit and then decide to remediate. I have no earthly idea what zeros and ones are in that code, but I start rolling the evening of patch Tuesday. I don't know the windows kernel better than the guys in Redmond, I am not going to correct them. I update the Dell BIOS every month blindly, I ain't got time to read through every release note regarding this month's yet another Intel VPRO cve across 30 models. I don't care to know the intricacies of a certain buffer overflow in the firmware for an HP4000 printer, it's getting the latest installed regardless of my understanding.
We have a testing process, but I am basically just grinding out a huge array of updates blindly, been doing that for 24 years now.
I don't need a better understanding of why we are doing a firmware update. If the vendor makes it available, it's getting installed. Just accept that updating is a constant never ending grind that is on a tight timeline. Know what happens if you wait 30 days to examine and pick apart and really understand the depths of a windows update? You get another new windows update dropped in your lap and the one you were looking over gets superseded.
I take that approach so that the Security guys don't bother me over and over, it works. I went from 2 dozen security tasks a month to barely any. I was like you, I used to loathe the stack of obscure tasks that Security was stuffing in my queue. I don't do any work for this, it is all automated, it just runs every night/week/month on a schedule. It took me a bit to construct all that but it was well worth it.
> I update windows every month "blindly", I don't sit back and wait for the ransomware to hit and then decide to remediate. I have no earthly idea what zeros and ones are in that code, but I start rolling the evening of patch Tuesday. I don't know the windows kernel better than the guys in Redmond
The guys in Redmond have sabotaged us way too many times with botched updates for us to not wait at least one week before rolling out MS updates.
Agreed test systems go the first week, production the next. I have bricked my fair share of devices in my time, that's not slowing me down. I can barely get all the straggler laptops updated before the next round comes through. There's just not much leeway in the schedule.
You're not wrong at all, this is absurd.
I'd insist on a copy of their report, and starting copying uplevels if you don't have it by end of business that day, with an email at end of day. If it's not there in the morning, email them "when can we expect to have this report of the vulnerabilities you have alerted us to", copying your and their manager. From there I'd draft another request to be sent be my manager, including the words, "This delay is putting us at unacceptable levels of business risk. We need to meet tomorrow to understand why we can't get a report of the vulnerabilities you have informed us of."
Honestly, this is on your manager, though. They need to be kicking this uplevel, now, to whomever both teams connect to.
> can you just upgrade to the latest firmware on everything and let me know when you did it?
In this case, a good course of action is to not make promises, but to internally prioritize fixed firmware. Hopefully you know which version isn't vulnerable, or know enough about the vulnerability to figure out, but the main reason not to make promises is because you can't be sure they've given you enough information to be sure.
But then, you wait for them to discover that it's missing from their report, instead of taking time out of your busy day to report back to an infosec GRC grunt. Track the update internally, even track via issue that there was supposed to have been a vulnerability so that you can answer Who/What/When/Why/How questions later, but don't reach out to tell them anything. You're really busy, after all. They'll figure it out.
This is easy for me to say because, for the most part, updating firmware is low-effort for us. The exceptions are mostly about vendor gatekeeping, not process. Years ago we used Compellent storage arrays among others, and they were perfectly cromulent Supermicro-hardware NetBSD-kernel units except that all updates were gated behind the vendor TAC, and presumably available based on keeping up service contract payments. Today we find it easier to use vanilla hardware and software as targets, and manage it the same way we manage all other vanilla servers.
Security ran a scan, and are throwing it over the wall at ops to deal with. Throw it back over the wall because they did not give you sufficient information. This surely is why DevOps and DevSecOps were created, so that different teams aren't just throwing things over the wall for other teams to deal with.
I would work with your boss and the security team to set expectations on what is needed for you to complete your job and the time frame you estimate to complete the patches. Others have recommended tickets which is always a good way to document communication. A lot of IT people hate polices and procedures but this is where they shine
Security Guy here. I use Rapid7 because it tells what patch or setting you need to fix. There are canned reports that highlight the patch or fix for vulns. I also let my IT team into the tool, so they can look themselves. I had an enablement session with them.
Your security team is worthless lol
Politics and conflict management are what bosses are for.
If they're bullying you into doing your work and theirs, escalate the issue.
Reinforce the need for going to a formal chain of command with tickets, emails and periodic reports from them, not the other way around.
Maybe you culturally think you arent in your setting. Our culture does not enable and does not take too well lazy people maliciously covering their own asses with emails trails to avoid work in their cushion job. Especially if they are not our bosses.
Put bluntly, I dont endorse and would tell to get lost lazy and malicious colleagues that dont do their end of work and come back asking for status updates about doing theirs and mine work. You sir, are a saint.
Last time a colleague set me up to do his work, I phoned our common manager and they ended up firing the guy. I was not the first and only one complaining tbh. I actually liked the guy, did not enjoy working nights to do mine and his work though.
If they are using a scanning tool like Nessus or Rapid7 it will provide this information. It does not always include useful instructions on remediation but it should be enough to find out.
Other things like the CIS benchmarks often include both audit and remediation step by step instructions.
I don't know whether to be validated or disappointed that this is apparently not uncommon. It sounds a lot like our team's headache right now.
Hundreds of security update tickets dumped onto Helpdesk all at once, with virtually no info to go off of but hostnames and maybe their users--could be anything from a couple internet browsers, to years worth of Windows major version changes. We ask for details or logs, and receive "they're kinda hard to read so it's not worth it, just get whatever you can find".
There's...better (i.e. automated & remote) ways to handle this, right? Than messaging each user at a company individually, and trying to schedule a time to manually stop by and run updates on half of the physical devices on site in between other actual tickets?
Open a ticket with the security team requesting details of the vulnerability and then mark all your tickets as blocked by the security team. Document, document.
This would not fly for a second here. The vulnerability management team is expected to file specific tasks for each problem they find, where we are then expected to track and update the status of remediation and agree on due dates. It's not perfect yet, we still get too many requests with no set "completion criteria" beyond "scanner says good", but we're getting there. If I got a request like this I'd be going straight to my boss.
I was complaining about how ours handles things but yeah this is terrible. I at least get a spreadsheet, they logged in and showed me how scans are setup, told me what the are most concerned about along with time-frames, and are entertaining me getting read access to track it myself while they just make sure I don't slack.
If security team has concerns, they should log a ticket to the platform support teams detailing the relevant products/vulnerabikities. None of this email/chat bs that is difficult to audit in terms of SLAs, content, and quality
Your manager needs to have a talk with their manager about how useless the tools they are using are. Either their department isn’t willing to pay for the right tools or the sec team is either lazy or incompetent or both. I’d steer clear of being confrontational with the security team. You certainly don’t have all the details so you don’t want to point fingers that don’t need pointing, or just make things contentious with a team you should want to work well and closely with.
Best of luck.
We recently created two security analyst positions. They were inside hires. One was a healthcare application support person (not any kind of IT admin experience) and the other a former network administrator. I was hired to fill the network admin role actually, so I replaced that person.
To be perfectly honest, I have far more experience than either of them, and have done a fair bit of helping them get and use the tools they need (Wazuh, OpenVas, SIEM monitoring/reporting etc.). So yeah, I feel where you are coming from and I’m sure there is a TON of this kind of thing happening all over. Creating and filling new roles with people who are new to the space, because the org needs to check a box for one reason or another. We are pretty rural, so finding a security expert willing to move here for not any kind of crazy salary just isn’t realistic. In our case, they’re not lazy or even incompetent even. Just growing into the role takes time really.
There have been examples similar to what you’re going through where we’ve had to pump the brakes on their expectations. We are short staffed across all IT, so we have to pick and choose what things that “need patched” really do NEED it. They do provide us with CVEs and other literature though. That’s just a given that needs addressed ASAP for your sake.
Not saying that’s what is happening where you are, but could be.
Not a salesman but go install Action 1 (100 endpoints free). It will scan for and automatically update CVE issues.
Goto your boss, point out this software automated their job and get them all fired.
Yeah, no. That's pretty silly.
I look after a lot of that side for our team (very small, I am not solely a security admin), and I ticket out in detail to our Helpdesk guy what needs to be chased up (if it's an end-user problem and I can't take the time to deal with it myself), or if it pertains to other people on the team (ie we have a guy that does dev work) I outline exactly what needs updating and how urgent it is.
All CVEs *should* be addressed where possible, but you're right, you can't do anything without even the slightest information to help you. I can't delegate to someone on my team with "\[x\] is vulnerable", refuse to elaborate, and then assume they're going to know exactly what it is.
This is a poorly managed security team with low end security people. House needs a serious overhaul and installed with seasoned professionals at the management and individual contributor level. I would suggest pushing back hard and escalating to your management for having your time wasted. This is unacceptable in a workplace to contact people without providing them any details on what you are contacting them for, having no real asks, and following up with no information of any usefulness weeks later.
Until they get their stuff together just escalate and let your manager so you can get back to making money. Saying something is vulnerable without providing details on what that it is specifically is like calling someone on the phone and just breathing without saying anything, then when you hang up they call and breath even harder each time until you can feel and smell their breath through the phone.
I was (breifly) guilty of this by exporting the report as a summary with no links. The report reader didn't catch it for a few months. All is well now.
No CVE, no action. And beyond that they should be providing a risk assessment - IE: can it wait for the next patching cycle, or does it need an out of phase patch.
Make them fill out a form. They want you to do something, but they don't want invest time, so you should need to ask the necessary questions only once (in the standard form aka ticket template).
LOL. I worked in a VM role and at a minimum, our reports gave you the exact vulnerabilities present on a system, the recommended fix for each vulnerability, the severities for each vulnerability, the exact item the scanner flagged / the version it picked up (where applicable), and the date of detection. We included more stuff but you get the idea. The first 2 are 100% required for the report to be actionable.
We also made it so that you can filter our reports by vulnerability (to see where specific vulnerabilities are in the environment) or by host (to see the issues a specific system has).
We also made sure that we prioritized things so that we’re weren’t just throwing reports at the admins and saying “fix this”. We wanted teams to have a starting point that would take care of the biggest bang for your buck / most dangerous stuff.
We also had recurring meetings with the IT teams to go over any questions they had about the reports, the findings, etc.
If your security team can’t even give you a stock Nessus report that outlines the vulnerable host, the specific vulnerability, and the fix, you need to have your management escalate this to their management. It’s really 2 minutes of effort to get a decent report out. You can even automate them. Or setup a dashboard.
Seeing this stuff pains me because it gives all of us on the security side a bad name.
It used to be like this, but we now have a power bi dashboard that reads from our SIEM. Everyone goes into the dash and looks up and deals with their CVEs.
But its never ending, as soon as you patch something, another pops up. It makes me want to give up IT and become a uber driver.
> I would be mad/annoyed if a sysadmin tried to hijack/step on my role so I'm staying in my lane. However, if I'm not properly doing my job then they would be justified in telling me where I'm lacking.
If you were doing your job properly you should never get a CVE notification from your security people.
You should be proactively patching, not reactively waiting for your security team to run their report.
Im on server infra - are our management had us waste countless hours to jump whenever security wanted we finally convinced them to STOP security until they could provide reasonable information in a reasonable format with reasonable expectations of resolution.
in the meantime, they kept nagging us, and they would even go right to application owners \[here we have a ton of on prem Health IT apps and app owners have a lot of access to app servers\] - asking them to manually update patches or products in the middle of the day, or ordering them to shut things off IMMEDITATELY until a resolution could be made. they were just straight emergency stopping healthcare constantly with their insane requests.
It took management forever to get higher ups involved to reign in security - the business has to accept some risk and set some boundaries and requirements for reporting risks and remediating issues and make it super clear to security that they have to chill out. And also to make it super clear to our infra teams that \*this\* does get taken seriously and we need to target X amount of time to remediate things.
I can send you a weekly report telling you that your office is vulnerable without any other info for much, much cheaper. Hire me instead! lol
There are a LOT of false positives that can get flagged in a security scan. I remember we have to educate the PCI-DSS guys once a year that they're running their own tests wrong. haha
This is a great example of why segmentation is sometimes a bad thing.
Wouldn't it be much wiser to have the scanner generate a report and forward that report to parties that it would involve?
No.
If the team is doing their actual job the infosec team will be assessing the vulns in the context of the organisation. Critical and external facing? Escalate that straight to someone important enough to get prioritisation or paid well enough to accept it. Critical and on an internal system 1 person users with no data on it... not so important. Sometimes a critical can be dropped to N/A. The reviewed info should then be passed along for prioritisation by the implementation teams/owners.
The team assessing and managing these risks will likely have a much better end-to-end picture than simply reporting it to operational teams for them to fix.
Depending on the size and structure of the org, this could follow with a different chain of mails to Upper Management indicating that, by order of the security team, all this systems will be updated and inaccesible by those dates, and that the risk of those updates impact to this and that lines of business. Like imagine telling a online shop business that yes, you're sorry, but security is very adamant in not telling exact info so all webservers and shops databases will be updated during black friday with possible impacts on all sales, and that you are forced to do general updates that may or may not solve anything, but apparently they have top priority unless they are not.
The idea is to put them in a room with their natural predators and see what happens.
Your [submission](https://www.reddit.com/r/sysadmin/comments/1dyegkw/not_sure_how_to_handle_these_requests_cves/) in /r/sysadmin was automatically removed because it appears to be empty. Please add some content. A headline or title is not sufficient content. If you feel this action is incorrect, please [message the moderators](https://www.reddit.com/message/compose?to=%2Fr%2Fsysadmin).
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/sysadmin) if you have any questions or concerns.*
Sounds like you have a garbage security team. They should be able to tell you exactly what the problem is, how it could impact the business, and how to fix it.
Yeah, they are doing just enough to say they are doing their job, but not actually be useful.
Arguably, their value-add is negative. They're asking OP to do something that OP may need to do anyway (updates are routine), but they're asking for priority and also asking for a special report back.
Checklist managers are the worst people. All of the power with none of the knowledge.
Agreed. In this case and scenario, their existence can be completely replaced by firing them and giving OP access to the scanner, or at the very least, the report itself.
So... just like every HR and insurance company team in existence. Sigh... ;)
auditors enter the chat
This is unfortunately an extremely common occurrence.
It sounds like the security team has the info and they are just lazy as fuck. "I've bene really busy, can you just go ahead and do a bunch of work that may or may not be needed and may not resolve the issue, just to save me the hassle of doing my own job". Fuck those guys.
Yeah, I run a security team, and definitely fuck those guys for not even giving a basic report.
Is one of the guys named Tyler?
The scanning tool our security team uses automatically exports a report. All that they do is put my email address in at the beginning of rhe scan. That apparently leaves them time to suggest mitigation techniques such as firewall zones if I can't remediate a CVE right away for some reason.
I agree with what the problem is and how it can impact the business, but the security team shouldn’t be expected know how to fix it past a list of options in the CVE.
They may not need to know all of the technical details of how to fix it, but they should know what the potential fixes and workarounds are, else how can they know if a vuln has been properly fixed or mitigated? To provide an example, consider the fortigate SSLVPN vuln CVE-2024-21762 - security team flag that you have fortigate devices on a version that has this vuln - but the vuln is only exploitable if you have SSLVPN enabled - if they're unaware that one of the fixes is to disable SSLVPN they'll keep saying you need to patch to mitigate, when you are fully mitigated already. It also doesn't sound like their security team even know which CVEs or other vulns they have, they're just saying "something is wrong" which is wholly unhelpful. IMO it's even worse than a user saying "My computer is broken, fix it" and providing you no info - because the security team do seem to have this info, they just won't share it.
Also sounds like an overworked security team, and how hard can it be to take a look at the version you are running, the latest version and what vulns are patched. You don’t need that security team for that.
What good is that if they're not giving him CVEs? Yup, something was patched...no idea if it's what they're talking about. Overworked? They're doing a scan that outputs a report. Send it to him and let him read it if they're too "busy".
If we were placing bets, I'd bet that their scanner popped something "informational" and they don't know what that means, they just want to be able to say they reduced "vulnerabilities and findings".
TLDR: They should be providing the information from the vulnerability scan. No way, fuck that bullshit. I might buy overworked if it took them a few days but they provided the requested information. Not all vulnerabilities have anything to do with "latest version" or "vulns patched". For example, and speaking from experience, once upon a time a vulnerability scan revealed a VM as accessible to the outside internet when it was not supposed to be at all. No amount of patching and updating would have addressed that. That guy just sounds like a lazy ass hat.
> how hard can it be to take a look at the version you are running, the latest version and what vulns are patched. The latest version of *WHAT*? It sounds like the absolute most information the security team are providing is possibly which server is affected, but even a single purpose server can be running many different bits of software, each with other libraries they rely on which may or may not be obvious. This is the exact reason we have vulnerability scanners, it's basically impossible to stay on top of every single piece of software and all of their individual libraries installed across every server in your environment. Even if you do update absolutely everything as soon as updates are available, that's no guarantee that the updates actually patch the vulns - look at the list of log4j/log4shell impacted software, and note that despite being a 3yr old vuln at this point, there are still some bits of software marked as affected (NOT fixed!), so update all you want - if the vendor hasn't patched it in their version of the library, you're still vulnerable.
I’m not sure what your security team is doing, but it isn’t proper vulnerability management. If they’re going to report a system as vulnerable, they have to provide the information as so why. Whether that be the CVE, or maybe even what they were scanning for. You can’t do the work, if you don’t know what the work to be done is.
Not to mention that updates to systems can produce backporting false positives. So, OP may be doing exactly what they need to do, and the scanner is popping a false positive based on a backport.
Ugh tenable, especially agentless, loves to do this with red hat systems (granted I know just having a version number makes it hard to figure out of its a red hat package with backported fixes and not really a 3 year old version)
>Hi, these devices are vulnerable I would expect that to be followed by As outlined here, here and here and this is relevant in our environment because of this this and this The following steps need to be taken to remedy, as outlined here here and here If I got a message saying : >Hi, these devices are vulnerabe My response would be "ohmygosh that's terrible"
And I'd carry on with my day until such time they got a grownup to help
Create a ticket template for them for CVEs. Have it require a link to the CVE in question as well as a link to the remediation. Don't accept any remediation work from them without it.
This approach worked well for us. Importing the CVSS automatically prioritises the ticket accordingly.
The infosec team in OP's org will never acquiesce to this, because it puts them one step away from being (appropriately) automated away.
Generate a ticket about the reported vulnerability. Add a list of the things you need to complete the ticket: 1. What devices are affected? 2. What is the specific CVE being reported? 3. What is the level of the vulnerability? 4. What is the Risk valuation of the vulnerability? Is it a minor vuln that affects 80% of systems? Or is it something that only effects a couple off systems, but the effects would be devestating in the event of compromise? 5. Are they Enterprise Systems or Operational Tech Systems? 6. What specific application is affected? 7. What is the criticality ranking of the system/processes that are affected? (example - is it a minor system that can wait, or is it a absolutely crucial to business process server There's about a dozen more elements you can add to the ticket questionnaire. Have a statement like "please list downtime available for scheduling to resolve this vulnerability patching" and "Work on vulnerability remediation will commence once this questionaire is completed. Then assign the ticket to whomever reported the vulnerability for remediation, and add their team lead or manager as a watcher on the ticket. This will punt the responsibility for data collection back in their court, and they won't be able to claim "I reported the vulnerability, but u/tdhuck didn't do it!"
[удалено]
My sec team created a security dashboard that contains pretty much everything I need: hosts, vulns, CVEs, and suggested fixes. I just check that daily. If something new shows in the list, I implement the fix. No communication necessary. We dropped our vulns by 80% in one month, and it continues to decline.
With a couple more steps depending on your ticketing platform, you can automate this ticketing response. For example in Service Now, or Jira, you can add a drop down option on opening a new ticket. Then its just kicking back the automated response, and you may be able to automate assigning the ticket back to the reporter and the reporting management with some other tweaks.
[удалено]
You should be able to open a ticket for that;
What's nuts is that most of that info should be a simple export from the vulnerability tool. We even give our Infrastructure team access to our tool so they can see all the details and check if their remediation's worked(agent based scans twice a day) without waiting for us to confirm(either adhoc or every other Friday during our Vulnerability committee meeting)
Exactly, but Op is dealing with an asshat whose apparently too lazy to hit an export report button and append it to his requests.
> Have a statement like "please list downtime available for scheduling to resolve this vulnerability patching" Why would the security team know this?
Many company’s security teams interface with the end users directly. Often the security teams have elevated corporate responsibilities and can either order or request downtime windows for vulnerability mitigation as part of their enforcement scope.
> Many company’s security teams interface with the end users directly. They do? That's news to me, tbh. The app owner should be the one interfacing with the end user and coordinating downtime. *Maybe* that's security for some apps but I really can't imagine that being the case at a company of any real size. Our security team has their hands full with their own jobs without also doing that of app support.
I’ll rephrase. *Effective security teams*
Please elaborate on why the security team needs to also be the app owner and do their job too in order to be effective.
They don’t need to be the app owner, but they should understand how the end user uses the application in their role. It’s not enough to know what the application is, or does. You have to know how the end user interacts with it. What steps they take, what ‘tricks’ and ‘shortcut’ they may try to pull… because if the end user thinks they can speed up their own processes by side stepping your security initiatives they will.
"They don't need to be the app owner, they just need to know everything about it and everything about how people use it". idk man that sounds a lot like an app owner.
I didn't say you need to know everything about it. I said you need to know specifically how the end user is using it. I'm passing on solid gold sage advice here.
Can you give an example here? I feel like we're on totally different wavelengths.
If the scanner is any good, it should have a plugin output or similar which describes proof of the vuln. Where I work, if this is missing then we assign the ticket back to the analyst that made it. Quite frankly, the vuln world has a lot of dead weight in it. You aren't asking for them to move mountains, it is just a checkbox in the export wizard. Tell these people to nut up or shut up. "something happened somewhere" is the type of description that is written by people who have zero intention of making a contribution and you don't need to give them the time of day.
Its such a shame that it became wider knowledge that IT sec pays well. Now all the morons who would have studied economics 10 years ago are piling in and plague technical people with BS like this. The only reason you may need a security person in terms of CVEs is for them to tell you if/what kind of problem it is and how to remediate it. Even just getting the CVE number should be completely automated by any decent tool.
In my experience, a lot of security guys don’t understand security. They only know how to drive the gui of a particular tool, and often not that well. I once had a whole big thing with our team when qualys flagged some DLL as being vulnerable and out of date. Problem was, the vulnerability only affected the Korean language version, which would never apply to our server. They just couldn’t understand.
This makes me regret not applying to those position i thought im not qualified for...
It’s entirely possible that you were both unqualified and the most qualified at the same time.
This would need to be escalated. I didn’t see anything wrong on your part, it’s whomever you’re working with. If you have a ticketing system, have them create a ticket and force them to enter in the needed information. “I’m sorry I didn’t grab that information” is not acceptable.
Just tell them their scanner is wrong, because it's producing CVEs that are invalid. Nobody should be able to get away with garbage requests like this. Have them escalate to nexpose or whoever else they're using. Unfortunately, infosec often is able to get away with such stupidity because everyone in the upper management is afraid of them. They should be submitting these sorts of requests through a standardized ticketing system, just like everyone else. And the tickets should be closed if they don't provide critical and/or requested information-just like with everyone else. Any company that has a dedicated infosec team better have a ticketing system, and there damn well better be formal processes for this. Reject with prejudice, and copy management in until they have a process.
Long ago when i used to care I'd have tried to pull info out ot them what the issue is make sure it's fixed... Later when I cared less I'd hound them for a ticket, but still try to patch stuff Now I'm approaching a point where I don't respond to bullshit emails, they know we have a ticketing system, they can use it or not. Now... I'll still patch things, on a as short schedule as is reasonable, automatically if possible. If I know of real vulns I can't patch I'll apply mitigations. But unless my boss asks I'm not responding to lazy morons. Or if it's a client, still trying to learn to forward it to a PM and forget about it.
Wow, and i thought our security team has quirks :D At least they gave ALL IT read-only access to scanning tool (Qualys). So anyone in our IT teams can go and check themselves and not wait until some burning reports come through to top management (some still do). And it provides not only a list of CVEs,. but also detected bits (registry/files) and usually supposed fix (e.g. version x fixes this issue). Your sec team is either insanely gatekeeping and afraid if they show what they have, someone will think they are not even necessary. Or they don't understand what scanner shows or how to get the info you are asking for (looking at some top level dashboard with hostnames and numbers of vulnerabilities only). And i am not sure which one is worse..
This security team could be doing more harm than good. Over my nearly 30 years in IT, I've seen any number of systems taken down by running patches/fixes that "fixed" things that weren't broken/vulnerable. This security team has no business asking you to patch if they won't provide the relevant CVE(s).
The absolute worst is garbage scanners and security staff that don't understand the concept of backporting. "Hi, SSH is vulnerable on this server due to CVE-XXX-XXXX." "We run EL, which has backported a patch for this in version x.y.z-123. Here's the changelog, as well as the exact revision we are running." "Hi, the scanner still says the version is vulnerable. Please fix it."
People love to hate on documentation but this is what happens when policy and governance isn’t created. Ideally you’d consult the vulnerability management policy and have a defined point to call out that the vulnerability management team is missing. Even better would be a RACI chart.
Fix this. It’s fixed. It’s still showing up in our scanner. Fix your scanner.
This sounds like a Manager or Director should become involved in this. Our Manager simply had us return those Tasks lacking information back into the Security Team's queue and he walked over and had a discussion with the CSO. Done in 10 minutes. That said, the Security dude is not exactly wrong about blindly updating firmware. We were inundated with security vulnerability tasks several years ago. I finally went over the top in the last few years. Aggressive windows patching, really aggressive 3rd party application patching, all devices (docks, laptops, printers) get latest firmware forced. Just a super over the top blasting of every known update. It worked, our security tasks are down to a trickle. When they quit getting hits on workstations and servers they started scanning printers, which are now all updated and even have new SNMP community names. We barely ever get tickets now and it's usually just a couple of crap devices that are out of diskspace or something like that. Here is another trick, when they do send you a good task with all the information and it lists only 10 affected assets then go setup automation to find the systems that security did not find on their scan. If there are 10 in the task there are probably another 15 in the environment that are also vulnerable. Setup logical automation to find them and leave it running.
[удалено]
Yeah, you have a leadership issue, not a technical issue. This is what a manager or director is hired to perform. You are in need of changing another IT sister team's process, that's clearly not in your pay grade. Delegate this straight to your manager. This is plainly in the wheelhouse of managerial work. Meanwhile, separately from this, go nuts upgrading everything. It's not a waste of time to be two steps ahead of Security team. Run Dell Command Update on your workstations, run HP WebJetAdmin on the printers. Don't do this manually, setup repeatable automation and just let it bake in the oven and churn while you work on other things. Then you never get the security task in the first place. Become proactive instead of reactive. All of my workstations are on the latest BIOS, they have the latest drivers for the month, they are all on the same OS and same feature update and the same monthly patch. All my printers have current firmware. All my docks are updated. All my 3rd party apps(filezilla, chrome, notepad++, Java, etc..) are updated. Security is not knocking on my door anymore because I have leapfrogged them.
[удалено]
Uh, ok, just forward each ticket you get to the Help Desk since those are the guys that update software revisions. That's how 99% of the vulnerabilities are fixed, the rest might be some post-update registry change. If they are not giving you that information, then you escalate up the chain of command. You seem to have an opportunity here to just slough this work off to another group, take it. Why are they sending to you if you are not even the responsible party? Honestly there is a micro-fine line between software and firmware in this day and age. It's just a command we run that installs an update. Most people are just panicked about the reboot. "Why should we update this?" answer: "don't care, it's available, let's roll it" I update windows every month "blindly", I don't sit back and wait for the ransomware to hit and then decide to remediate. I have no earthly idea what zeros and ones are in that code, but I start rolling the evening of patch Tuesday. I don't know the windows kernel better than the guys in Redmond, I am not going to correct them. I update the Dell BIOS every month blindly, I ain't got time to read through every release note regarding this month's yet another Intel VPRO cve across 30 models. I don't care to know the intricacies of a certain buffer overflow in the firmware for an HP4000 printer, it's getting the latest installed regardless of my understanding. We have a testing process, but I am basically just grinding out a huge array of updates blindly, been doing that for 24 years now. I don't need a better understanding of why we are doing a firmware update. If the vendor makes it available, it's getting installed. Just accept that updating is a constant never ending grind that is on a tight timeline. Know what happens if you wait 30 days to examine and pick apart and really understand the depths of a windows update? You get another new windows update dropped in your lap and the one you were looking over gets superseded. I take that approach so that the Security guys don't bother me over and over, it works. I went from 2 dozen security tasks a month to barely any. I was like you, I used to loathe the stack of obscure tasks that Security was stuffing in my queue. I don't do any work for this, it is all automated, it just runs every night/week/month on a schedule. It took me a bit to construct all that but it was well worth it.
> I update windows every month "blindly", I don't sit back and wait for the ransomware to hit and then decide to remediate. I have no earthly idea what zeros and ones are in that code, but I start rolling the evening of patch Tuesday. I don't know the windows kernel better than the guys in Redmond The guys in Redmond have sabotaged us way too many times with botched updates for us to not wait at least one week before rolling out MS updates.
Agreed test systems go the first week, production the next. I have bricked my fair share of devices in my time, that's not slowing me down. I can barely get all the straggler laptops updated before the next round comes through. There's just not much leeway in the schedule.
You're not wrong at all, this is absurd. I'd insist on a copy of their report, and starting copying uplevels if you don't have it by end of business that day, with an email at end of day. If it's not there in the morning, email them "when can we expect to have this report of the vulnerabilities you have alerted us to", copying your and their manager. From there I'd draft another request to be sent be my manager, including the words, "This delay is putting us at unacceptable levels of business risk. We need to meet tomorrow to understand why we can't get a report of the vulnerabilities you have informed us of." Honestly, this is on your manager, though. They need to be kicking this uplevel, now, to whomever both teams connect to.
> can you just upgrade to the latest firmware on everything and let me know when you did it? In this case, a good course of action is to not make promises, but to internally prioritize fixed firmware. Hopefully you know which version isn't vulnerable, or know enough about the vulnerability to figure out, but the main reason not to make promises is because you can't be sure they've given you enough information to be sure. But then, you wait for them to discover that it's missing from their report, instead of taking time out of your busy day to report back to an infosec GRC grunt. Track the update internally, even track via issue that there was supposed to have been a vulnerability so that you can answer Who/What/When/Why/How questions later, but don't reach out to tell them anything. You're really busy, after all. They'll figure it out. This is easy for me to say because, for the most part, updating firmware is low-effort for us. The exceptions are mostly about vendor gatekeeping, not process. Years ago we used Compellent storage arrays among others, and they were perfectly cromulent Supermicro-hardware NetBSD-kernel units except that all updates were gated behind the vendor TAC, and presumably available based on keeping up service contract payments. Today we find it easier to use vanilla hardware and software as targets, and manage it the same way we manage all other vanilla servers.
This makes me appreciate mine more.
Security ran a scan, and are throwing it over the wall at ops to deal with. Throw it back over the wall because they did not give you sufficient information. This surely is why DevOps and DevSecOps were created, so that different teams aren't just throwing things over the wall for other teams to deal with.
You are in the right here. Blindly upgrading firmware is a horrible idea. You need to understand what the risk is before you can react to it.
This is not common. Your security team is bad.
Saying they're bad is an understatement; they're downright lazy. They never lift a finger and expect everyone else to pick up the slack.
I would work with your boss and the security team to set expectations on what is needed for you to complete your job and the time frame you estimate to complete the patches. Others have recommended tickets which is always a good way to document communication. A lot of IT people hate polices and procedures but this is where they shine
"I'm sorry but at this time I am not accepting un-actionable feedback."
Security Guy here. I use Rapid7 because it tells what patch or setting you need to fix. There are canned reports that highlight the patch or fix for vulns. I also let my IT team into the tool, so they can look themselves. I had an enablement session with them. Your security team is worthless lol
How big is your company? Take this to your boss or CIO.
[удалено]
Politics and conflict management are what bosses are for. If they're bullying you into doing your work and theirs, escalate the issue. Reinforce the need for going to a formal chain of command with tickets, emails and periodic reports from them, not the other way around.
[удалено]
Maybe you culturally think you arent in your setting. Our culture does not enable and does not take too well lazy people maliciously covering their own asses with emails trails to avoid work in their cushion job. Especially if they are not our bosses.
[удалено]
Put bluntly, I dont endorse and would tell to get lost lazy and malicious colleagues that dont do their end of work and come back asking for status updates about doing theirs and mine work. You sir, are a saint. Last time a colleague set me up to do his work, I phoned our common manager and they ended up firing the guy. I was not the first and only one complaining tbh. I actually liked the guy, did not enjoy working nights to do mine and his work though.
If they are using a scanning tool like Nessus or Rapid7 it will provide this information. It does not always include useful instructions on remediation but it should be enough to find out. Other things like the CIS benchmarks often include both audit and remediation step by step instructions.
I don't know whether to be validated or disappointed that this is apparently not uncommon. It sounds a lot like our team's headache right now. Hundreds of security update tickets dumped onto Helpdesk all at once, with virtually no info to go off of but hostnames and maybe their users--could be anything from a couple internet browsers, to years worth of Windows major version changes. We ask for details or logs, and receive "they're kinda hard to read so it's not worth it, just get whatever you can find". There's...better (i.e. automated & remote) ways to handle this, right? Than messaging each user at a company individually, and trying to schedule a time to manually stop by and run updates on half of the physical devices on site in between other actual tickets?
If it's not important enough for them to send the info, then it's not important enough for you to do the work.
Open a ticket with the security team requesting details of the vulnerability and then mark all your tickets as blocked by the security team. Document, document.
This would not fly for a second here. The vulnerability management team is expected to file specific tasks for each problem they find, where we are then expected to track and update the status of remediation and agree on due dates. It's not perfect yet, we still get too many requests with no set "completion criteria" beyond "scanner says good", but we're getting there. If I got a request like this I'd be going straight to my boss.
As a Security guy, this is nonsense. CC your manager and their manager, and rehash this conversation. That response is unacceptable.
I was complaining about how ours handles things but yeah this is terrible. I at least get a spreadsheet, they logged in and showed me how scans are setup, told me what the are most concerned about along with time-frames, and are entertaining me getting read access to track it myself while they just make sure I don't slack.
If security team has concerns, they should log a ticket to the platform support teams detailing the relevant products/vulnerabikities. None of this email/chat bs that is difficult to audit in terms of SLAs, content, and quality
Your manager needs to have a talk with their manager about how useless the tools they are using are. Either their department isn’t willing to pay for the right tools or the sec team is either lazy or incompetent or both. I’d steer clear of being confrontational with the security team. You certainly don’t have all the details so you don’t want to point fingers that don’t need pointing, or just make things contentious with a team you should want to work well and closely with. Best of luck.
[удалено]
We recently created two security analyst positions. They were inside hires. One was a healthcare application support person (not any kind of IT admin experience) and the other a former network administrator. I was hired to fill the network admin role actually, so I replaced that person. To be perfectly honest, I have far more experience than either of them, and have done a fair bit of helping them get and use the tools they need (Wazuh, OpenVas, SIEM monitoring/reporting etc.). So yeah, I feel where you are coming from and I’m sure there is a TON of this kind of thing happening all over. Creating and filling new roles with people who are new to the space, because the org needs to check a box for one reason or another. We are pretty rural, so finding a security expert willing to move here for not any kind of crazy salary just isn’t realistic. In our case, they’re not lazy or even incompetent even. Just growing into the role takes time really. There have been examples similar to what you’re going through where we’ve had to pump the brakes on their expectations. We are short staffed across all IT, so we have to pick and choose what things that “need patched” really do NEED it. They do provide us with CVEs and other literature though. That’s just a given that needs addressed ASAP for your sake. Not saying that’s what is happening where you are, but could be.
Not a salesman but go install Action 1 (100 endpoints free). It will scan for and automatically update CVE issues. Goto your boss, point out this software automated their job and get them all fired.
sounds like your security team SUCKS. Mine provides me with way too much information, which i much prefer.
Kick the ticket back requesting the info...Out of your hands until then.
Yeah, no. That's pretty silly. I look after a lot of that side for our team (very small, I am not solely a security admin), and I ticket out in detail to our Helpdesk guy what needs to be chased up (if it's an end-user problem and I can't take the time to deal with it myself), or if it pertains to other people on the team (ie we have a guy that does dev work) I outline exactly what needs updating and how urgent it is. All CVEs *should* be addressed where possible, but you're right, you can't do anything without even the slightest information to help you. I can't delegate to someone on my team with "\[x\] is vulnerable", refuse to elaborate, and then assume they're going to know exactly what it is.
Is there a ticket?
This is a poorly managed security team with low end security people. House needs a serious overhaul and installed with seasoned professionals at the management and individual contributor level. I would suggest pushing back hard and escalating to your management for having your time wasted. This is unacceptable in a workplace to contact people without providing them any details on what you are contacting them for, having no real asks, and following up with no information of any usefulness weeks later. Until they get their stuff together just escalate and let your manager so you can get back to making money. Saying something is vulnerable without providing details on what that it is specifically is like calling someone on the phone and just breathing without saying anything, then when you hang up they call and breath even harder each time until you can feel and smell their breath through the phone.
I was (breifly) guilty of this by exporting the report as a summary with no links. The report reader didn't catch it for a few months. All is well now.
yeah that's dumb, in my role I can see vulns for our systems plus run remediation scans to see if I've been able to fix them.
No ticket with details, no work. Also, I follow Change Management process.
No CVE, no action. And beyond that they should be providing a risk assessment - IE: can it wait for the next patching cycle, or does it need an out of phase patch.
holy crap i appreciate my infosec team now
You’re telling me that your security actually reports vulnerabilities to you?! Must be nice.
Make them fill out a form. They want you to do something, but they don't want invest time, so you should need to ask the necessary questions only once (in the standard form aka ticket template).
You have a shit security team end of
LOL. I worked in a VM role and at a minimum, our reports gave you the exact vulnerabilities present on a system, the recommended fix for each vulnerability, the severities for each vulnerability, the exact item the scanner flagged / the version it picked up (where applicable), and the date of detection. We included more stuff but you get the idea. The first 2 are 100% required for the report to be actionable. We also made it so that you can filter our reports by vulnerability (to see where specific vulnerabilities are in the environment) or by host (to see the issues a specific system has). We also made sure that we prioritized things so that we’re weren’t just throwing reports at the admins and saying “fix this”. We wanted teams to have a starting point that would take care of the biggest bang for your buck / most dangerous stuff. We also had recurring meetings with the IT teams to go over any questions they had about the reports, the findings, etc. If your security team can’t even give you a stock Nessus report that outlines the vulnerable host, the specific vulnerability, and the fix, you need to have your management escalate this to their management. It’s really 2 minutes of effort to get a decent report out. You can even automate them. Or setup a dashboard. Seeing this stuff pains me because it gives all of us on the security side a bad name.
It used to be like this, but we now have a power bi dashboard that reads from our SIEM. Everyone goes into the dash and looks up and deals with their CVEs. But its never ending, as soon as you patch something, another pops up. It makes me want to give up IT and become a uber driver.
Do your own CVE scanning, and deal with the output of your own scans.
[удалено]
> I would be mad/annoyed if a sysadmin tried to hijack/step on my role so I'm staying in my lane. However, if I'm not properly doing my job then they would be justified in telling me where I'm lacking. If you were doing your job properly you should never get a CVE notification from your security people. You should be proactively patching, not reactively waiting for your security team to run their report.
You don't need to 'get paid to do that'. You are pad to be an effective sysadmin. Be an effective sysadmin.
Im on server infra - are our management had us waste countless hours to jump whenever security wanted we finally convinced them to STOP security until they could provide reasonable information in a reasonable format with reasonable expectations of resolution. in the meantime, they kept nagging us, and they would even go right to application owners \[here we have a ton of on prem Health IT apps and app owners have a lot of access to app servers\] - asking them to manually update patches or products in the middle of the day, or ordering them to shut things off IMMEDITATELY until a resolution could be made. they were just straight emergency stopping healthcare constantly with their insane requests. It took management forever to get higher ups involved to reign in security - the business has to accept some risk and set some boundaries and requirements for reporting risks and remediating issues and make it super clear to security that they have to chill out. And also to make it super clear to our infra teams that \*this\* does get taken seriously and we need to target X amount of time to remediate things.
I can send you a weekly report telling you that your office is vulnerable without any other info for much, much cheaper. Hire me instead! lol There are a LOT of false positives that can get flagged in a security scan. I remember we have to educate the PCI-DSS guys once a year that they're running their own tests wrong. haha
This is a great example of why segmentation is sometimes a bad thing. Wouldn't it be much wiser to have the scanner generate a report and forward that report to parties that it would involve?
No. If the team is doing their actual job the infosec team will be assessing the vulns in the context of the organisation. Critical and external facing? Escalate that straight to someone important enough to get prioritisation or paid well enough to accept it. Critical and on an internal system 1 person users with no data on it... not so important. Sometimes a critical can be dropped to N/A. The reviewed info should then be passed along for prioritisation by the implementation teams/owners. The team assessing and managing these risks will likely have a much better end-to-end picture than simply reporting it to operational teams for them to fix.
Depending on the size and structure of the org, this could follow with a different chain of mails to Upper Management indicating that, by order of the security team, all this systems will be updated and inaccesible by those dates, and that the risk of those updates impact to this and that lines of business. Like imagine telling a online shop business that yes, you're sorry, but security is very adamant in not telling exact info so all webservers and shops databases will be updated during black friday with possible impacts on all sales, and that you are forced to do general updates that may or may not solve anything, but apparently they have top priority unless they are not. The idea is to put them in a room with their natural predators and see what happens.
Your [submission](https://www.reddit.com/r/sysadmin/comments/1dyegkw/not_sure_how_to_handle_these_requests_cves/) in /r/sysadmin was automatically removed because it appears to be empty. Please add some content. A headline or title is not sufficient content. If you feel this action is incorrect, please [message the moderators](https://www.reddit.com/message/compose?to=%2Fr%2Fsysadmin). *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/sysadmin) if you have any questions or concerns.*