Partnerships Between IT and Security

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

Video Transcription
less than 3.3 partnerships between I, T and Security.
The objectives for this lesson is to understand the dependencies that I, T and cybersecurity have on each other and the importance of a good working relationship between the two teams and identify common areas of responsibility for I t. And how those may affect Sirte.
Okay, let's talk about the relationship between I T and cybersecurity, and this could be a delicate, an interesting relationship. I'll share a few stories as we go through here and maybe some best practices.
But remember that I t Security is on Lee there because I t. Is there.
So there is certainly a dependency between I t and cybersecurity or I t. Security or whatever the organization is called.
The reporting structure of security can make a difference on the relationship as can leadership. So earlier, when I showed you those flow charts and organizational charts of I T Security and how they might fit into an organization and how the CERT fits in,
there's certainly some things to be said for how the leadership within security reports into the larger organization.
So if you've got a c i o for example that
understands the importance of security and makes it a priority, and security falls under the CEO organization. It may be a great opportunity for collaboration and communications between security and I t people cause they're all on the same team. Essentially, if
security is a completely separate, different organization than I T, sometimes that can cause some additional problems. It depends on two I've seen where security reports up to the chief risk officer and I t reports up to the chief operations officer. And then there can even be conflicts at that C suite level
or even above maybe the CEO. And this is so both report to the CEO, but their peers and there's some conflict and pull it politics there, too. So this is not necessarily an easy thing to deal with. Sometimes it's great. Sometimes it's really difficult.
But it's also helpful. No matter what the reporting structure is, is to use a framework like racy. If you remember when we went through that, who's responsible? Accountable? Who needs to be consulted and informed on decisions
that can help make things very clear on who is responsible for what and it can help in discussions. Just to have that up is a constant reminder for these things. I t handles it for these things. Cybersecurity handles it, and here's all the different touchpoints, and it also can help make sure that people are talking to each other,
particularly in the consulted and informed
sections of your racy chart. I t. Maybe under resourced or lack maturity in security areas. I've seen this in the past where I t may want to do the right thing, but they just don't know how to do it or they lack tools. They maybe they don't have an automated way to patch or to do vulnerability, scanning or
any number of things that they just can't get done or they don't even know they need to be doing so. Sometimes you just have to help. I t
prioritized things and understand what is most impactful. From a security standpoint,
I t should maintain accurate documentation. This doesn't always happen. Of course, they should have good change. Management change management boards cm DBS We've already talked to system plans for systems and networks, I say should, but it's not normally the case, and I'm not speaking ill of.
I T organizations out there. It's just the reality that many of these organizations
are understaffed, underfunded, under resourced. And so when they're being told by leadership, go implement this tool, go get a contract for this cloud provider. Make all these upgrades to our human capital management software program. Documentation quickly falls behind.
And you really need leadership to understand the importance of these things and the vote time to them
toe work correctly and not impact the biz, the business or the mission. I T and Security have to collaborate, and they have to partner on shared goals and objectives. This is again why risk management and having those discussions at a very high level are so important because if you just can't get
the attention of I t. Leadership to get some of this stuff done.
But you have a nightie risk register, and you can highlight that
things aren't getting patched. And if these systems were to be compromised, then it would affect business Unit 12 and three. It would impact our supply chain. It would impact our ability to manufacture goods. We couldn't provide this service.
Those are the conversations that will get attention and hopefully get. The resource is that you need to get these things remediated.
Quiz question For this quick lesson. What is one way leadership can help define the roles and responsibilities of I T and security teams?
A strategic plan.
Be all hands meetings, see using a racy chart
or D the company Internet page.
The answer here is. See using a racy chart. Remember the discussion about having
what it is responsible for an accountable and consulted, an informed and the same with cybersecurity can really be a useful tool when you start going down the road of
who's doing what, who's responsible for what and also I've even seen organizations blow those things up and have them on a wall in a shared I T conference room, for example, to make it perfectly clear, not this. Shove it in their face kind of away. But just
if conversations happen and questions come up about well, who is responsible for vulnerability? Scanning? Well, looks looking are racy chart
that really can help those conversations, and it reminds people that you have that resource and they should go look at it when they're not sure.
So in summary with this lesson. We talked about dependencies between I T and cybersecurity and how they depend on each other
and also the common areas of responsibility for I t. And how those may affect Sirte.
Up Next
Service Level Agreements (SLAs) and Metrics to Monitor Protection Abilities
Zero Trust Networks (ZTN), Edge Computing and Other Considerations
Prevention is Ideal, but Detection is a Must
SIEM, SOAR and Security Analytics
Incident Response Taxonomy and Triage