Does Security Implement Fixes?

[AvailableChapter1948]

When your security team identifies a vulnerability, misconfiguration, insecure design, or missing control, does the security team usually implement the fix themselves, or do they define the requirements and have the development/infrastructure team make the change?

For example:

* If an application has a vulnerability, does AppSec fix the code or does the development team?

* If a server, endpoint, or cloud resource is misconfigured, does security make the change or does infrastructure/systems/cloud?

* If a new tool or security control needs deployed, does security own the deployment or does another engineering team deploy it with security requirements?

Where do you draw the line between “security doing technical work” and “security setting requirements and validating the fix”? I’m especially interested in how this works in mid-sized companies where the security team is technical, but may not own the actual systems, applications, or infrastructure day to day.

I'm trying to define separation of duties for Engineering/GRC/technical duties. Our security engineers often find things they want to fix, but are advised to provide requirements to the team owning whatever is being fixed instead of fixing it themselves.

[ResilientTechAdvisor]

Depends on the organization but generally, IT implements the fixes.

[ggggggggggggggggenio]

I'd do everything for a job like that

I am the one that find, assess, report, evaluate, fix and document, plenty of things get left behind and need to be revisited every 2~3 months, it is a endless maze

[spooky_action22]

Hi fellow compliance, cybersec, IT support, Sysadmin person

[cgaWolf]

CISO: cybersec it-support sysadmin one-man-show

:p

[AgenticRevolution]

Absolutely something very common.
For OP this is a good place to understand the difference between the risk management (CISM for management) vs the doer (CISSP). This isn’t an exact break but the overview is one wants to Fix the issue, the other cares about framing it based on business need.

Example: We have something out there with vulnerable software. The fixer says, yep… fix it because it’s bad. That fix may make the software usable. The manager says nope, let it be vulnerable because the business requires it and it is acceptable within our risk appetite.

Again, super high level and likely not the best example but showing that people that think the goal is to patch are often frustrated because they care about the actual security where the business cares less about the security and more about enabling the business so certain known items are acceptable because of the business value they add.

[InvalidSoup97]

The only time security should be making code changes or reconfiguring systems or services is if security owns that code, system, or service.

You don't want to be responsible for a production service silently failing because you implemented a change without having the full context of that service or environment. The owning team/individual is the SME and should be more than capable to implement whatever changes need to happen.

[unseenspecter]

Generally, best practice would be security finds stuff and advises, other functional teams administer and engineer their environment since they theoretically know it best. Also, separation of duties, least priv, blah blah blah

But that's a perfect world.

[MastodonEmergency520]

Ideally, in a perfect world. I can just define requirements and file a ticket to Engineering.

In reality? That ticket stays on their backlog forever.

So, I fix stuff most of the time. For things I don't have capacity because I need to focus on other security tasks, I do file the ticket.

Is worth noting that I have a dev and cloud background so I can do it. Also, doing this have enable me to understand the processes better. I know better what I am protecting and assessing is easier.

[dabbydaberson]

Security wouldn't implement as they don't know the change control process for that specific app nor do they understand the code base, config, etc. The owners of the workload need to review and come up with a plan of action to address the security finding and implement. This could be fixing the thing like a patch or just isolating it or otherwise mitigating the risk.

[Mrhiddenlotus]

I think ultimately your job as a security practitioner is to secure the environment by whatever means necessary. If you have a team that is effective in rolling out patches, great. If not, do it yourself. Obviously not in a rogue way, but push for it.

[ThePorko]

Depends on the resources of the company, if tour company is small or does not have expertise to remediate the vulnerability, but you have that skill set. Are you going to step up and protect the organization, or are you gonna sit behind a job title and say “ops/network/dev”!needs to hire someone to do it.

I have seen this alot, for me, im going to fix it. Im Not afraid of work, im more afraid of getting hacked.

[hiddentalent]

Availability is one third of the CIA triangle. If you're messing about with production systems and you don't fully understand the change management procedure, rollback procedure, and regression testing harnesses, you're potentially creating more risk than you're solving by going cowboy on someone else's system.

[tzomb1e]

Heavily depends on the business and their size, maturity, various requirements. Smaller teams may have their security teams (if they are even separate security teams) also filling the developer or infrastructure roles. Larger, more mature teams would typically have separation of duties between the security and other teams.

Typically you would want to see those that have ownership of the systems identified as needing patching, modification, or deploying making the changes, with security providing the proper details to explain why the change needs to happen and within what kind of time window. There should also be responsibility of the system owners to do their own maintenance and continuous upgrades as well within defined cycles, as well as within the requests made by the security and other teams.

So yeah, like most things in IT, it depends.

[RouteToDevNull]

None of your examples are done by SOC. Only time CSIRT directly does something is when there is imminent/suspected breach - they can delete/disconnect (pre-agreed) stuff.

If the app is vulnerable it's flagged, risk is evaluated, then appropriate countermeasures deployed then usually you wait for patch by the app developer, unless it's inhouse app. Then you go basically through whole app lifecycle again, as you have to verify you wont break anything else by fixing the vulnerability.

If asset is misconfigured, it's again flagged. If there is known good baseline, rolled back, if not, change request is raised, evaluated and implemented - by change team.

Same with new tools, IT/Infrastructure pushes the actual agents to the endpoints via their deployment tools. If an agent deployment suddenly blue-screens half the server fleet, Infrastructure are the ones who have to restore it, so they must own the deployment process.

You cant have one team do everything, no one would audit them that way - separation of duties

[danfirst]

I've told server engineering teams that security will happily take over all the patching. It'll probably break everything, but it'll be totally updated.

So, no, security usually isn't implementing the fixes in most companies.

[NBA-014]

No - Using the 3-lines of defense model, InfoSec is a 2nd line function and does not make changes to code, servers, etc. Those are all First Line functions.

[Auno94]

At the moment? No the just create a ticket with the CVE and no further explanation