IT and IS processes

Eva Belyaeva, Security Vision

Earlier we discussed the points of contact between IT and IS in terms of technical solutions, scenarios of their use and experience sharing.

Now we need to go a level higher and understand where all the contradictions and problems start - to the processes.

Common processes

Both IT and IS departments in a company may be wholly or partially responsible for the company's internal processes. Some of them may be specific and belong only to one of the teams, while others are more general and even ‘business’, there the zones of influence and responsibility are grey and blurred.

1. testing

Testing of any innovations, especially those related to installation of new solutions of any class, business history (reliability and recovery testing) - all this is done by both teams in the context of their own infrastructure. Sometimes there are overlaps when it comes to, for example, a new virtualisation platform, a new service - and then we have to work together, not in parallel.

2. Support

Support can be both internal user support and support aimed at the same solution stack; but in both cases there is a place for IS: the notorious awareness and hardening recommendations/tasks based on the results of pentest and incident handling.

3. Development and SSDLC

We discussed the role that security people play in development in an earlier article.

But also the fact that development and any git often relies on support and administration from IT should not be forgotten. At the intersection, this is what it is like to have multiple teams working fully on the same process, mostly without apparent conflict.

4. System analysis, system design

The business says how it requires. IS says how to fulfil these requirements with an eye on security. And already IT will be responsible for the implementation in one way or another. We are talking about teamwork again, only here there is room for disputes and different areas of responsibility - because each team will have its own vision and its own resources to solve the problem.

5. Risk Management

To be honest, risk managers are a separate people, with their own rules. But anyway, every process has that cornerstone of efficiency vs. reasonableness, speed vs. set rules.

6. Vulnerability Management

This is a process that is difficult to work with because IT is responsible for its implementation, and both can set such tasks. While IT often has a clear plan or resources, on the IS side there are requirements and knowledge of how to prioritise the threats behind vulnerabilities; the need to adhere to clear deadlines, as the security and operations of the entire company may depend on it.

7. Asset Management

Often this process is associated only with IT, but if we look at the same NIST and its phases of incident handling, we see that the first two phases are responsible for understanding what you own. And it's the knowledge of the infrastructure, the internal interconnections, and the ability to influence that that is required by IS. This entails trying to separate the capabilities of the teams as much as possible - as we covered earlier, asset management systems can be different for each team and not overlap at all, even though the process is essentially common.

8. Incident Management

Whilst the name itself suggests that this process relates specifically to IS, company policies very often stipulate that proactive response actions are only carried out through the IT team. Whether this is because analysts cannot be trusted to do so, or because the decisions through which such actions are implemented are within the IT team is not important. What matters is that there is absolutely no way to do anything meaningful in this process without collaboration.

9. Change Management

When it comes to the proverbial hardening and post-incident activities, it seems as if the implication is that IS speaks and IT executes, although this is not always the case.

It's not enough to shape and issue recommendations for the infrastructure, there is a journey ahead to protect any innovation first for IT and then for the business.

10. Configuration Management

This process is managed in the same way as the previous one, they go together.

11. Patch Management

Mostly here we can talk about vulnerabilities, but sometimes it is also related to development processes - problems found during testing and code reviews in own product also entail a chain of approvals and disputes - how much it is needed at a particular moment, how effective it is.

12. Compliance

In spite of the fact that compliance requirements are more important for business, it is the security specialists who work with them, both in terms of awareness and process organisation. And in order for this process to exist in principle, it must be based on the work of the IT department.

13. BCM (business continuity management), process management

Surprisingly enough, but even such seemingly ‘purely business’ processes contain subprocesses and asset management, as well as work with security, as testing is carried out for IS solutions as well. Business continuity as a whole depends on the coordinated work of the two teams.

Common difficulties

1. Communication

It can be hard to set up communication if the departments exist as separate as possible. If procurement is done with each one separately, requirements are not harmonised and there is no platform for interaction.

2. Priorities

Using patch management and vulnerability management as examples, we can see that the goal of IT and IS are sometimes different things that may conflict with each other.

3- Accountability

This is probably the biggest thing that catches the eye. All those policies and definitions of who can do what and who can't do what is the first thing you'll hear as an answer to the question of contradictions.

4 Expertise

Different levels of expertise and competence can often be the cause of poor communication. After all, if two teams speak different languages and don't have a ‘translator’, how will they agree?

5. Communicating with the business

Sometimes IT is closer to business issues, sometimes IS, depends on the company. Nevertheless, almost always someone's needs coincide with the company's main vector, and someone has to additionally protect them.

6. Process change

In principle, it is very difficult to take and start working in a different way. It is very difficult to reorganise, especially where the process is already well-established and has shown its effectiveness.

Ways of solution

1- Joining forces for common processes

Recruiting a common team that includes participants from different departments can help, as can implementing a process from the list above that takes into account the participation and needs of both departments. An internal lab will see such projects through to completion together, combining strengths.

2. A unified strategy from the business

IT and IS are equally valuable in a company, and if one side of the scales is continuously filled while forgetting about the other, the imbalance will sooner or later make itself felt. It is impossible to get a good result without combining competences and practices from both sides.

3- Exchange of experience and personnel

Sometimes it is useful to work for a while in a team of people whose activities are not quite clear and transparent to you. In some cases, facing the same complexities that people go through every day in their work is somewhat sobering and allows you to think about how to solve these problems instead of making them worse.

4- Sharing the technology stack

As we described earlier, there are so many useful solutions that can improve the efficiency of both IS and IT. Sharing this knowledge, technology, and expertise can routinely bring a new level of comfort and efficiency.

In general, healthy communication and the absence of imposed competition and stereotypes that come from both business and ordinary users help to solve most of the problems and disagreements.