Building Cyber Service

Building a service within an enterprise is not significantly different from building a new company. The main difference is that you don’t need to acquire customers. What I mean is that if you mess it up, the service will still exist and be used, and its manager can create weekly PowerPoint reports. People who depend on it may not like it but will use it, as there is no alternative.This lack of need for customer validation is also the main problem. People in management positions can't or don't know how to build a service because they never had to compete with alternatives. Something inevitable in "open market".

There are two main parts of a service life cycle: design and build, and use. In the enterprise world, you would refer to it as “change” versus “operations.” Different teams and individuals execute and are involved in each of these two phases.

If you want to change something, such as building a new service, you obtain funding for the project, gather resources, and assemble a team to create the new offering. Once it is complete, you need to hand it over to an operations team. The issue is that the project—this change—often focuses solely on technology. The service aspect is frequently considered out of scope and overlooked or ignored until the point when this new service should be utilized.

When the time comes, the operations team tries to determine how to use it and how to derive value from it. If it’s a customer-facing service—unless it presents a completely new proposition to customers—it will simply be “plugged” into an existing app. Whether customers use it or not is not measured; there are no pre-defined criteria to indicate whether the new “service” was worthwhile or what the ROI is.

If it’s internal service, it becomes even more complicated because, unless you have a strong service management and production team that knows how to proceed, the effort put into “implementing the service model” is much harder to measure, as no one knows what the criteria should be. Even though placing any piece of technology into a proper service context accounts for 80-90% of the effort measured by the number of people involved and the time needed, obtaining the most value from a new technology through its service model requires company-wide communication. This includes working with other operational teams within the enterprise and reaching out to teams or executive officers in teams that are supposed to use it.

If we focus on building cybersecurity services, the situation is even worse. The first hurdle is getting the intended operations team to understand the technology in the first place. When you reach the point where service requirements should start shaping the technology, there is a significant gap in understanding and knowledge. This can lead to various negative outcomes. Either the technology is altered to such an extent that it creates security and functional problems, or the service model fails to account for technological requirements, resulting in a poor user experience and diminished value of the service overall.

Is there a way out of this? Of course, but not many enterprises can work it out internally, as it requires a significant change in culture—reinforcing ownership. One of the most famous examples is linked to people from what’s called the PayPal Mafia. When you look at the beginnings of PayPal, its structure was geared toward the quick implementation of new ideas; there are books and countless articles about how the company was internally structured and managed. PayPal had a very agile and competent model that was able to deliver results. At the core of that model was ownership. One person was in charge of a project from the inception of an idea through delivery to operationalization—making it a successful part of the company’s portfolio or improving internal processes. This feeling and culture of responsibility and ownership is something that has weakened, at least in large UK companies.

I’ve experienced two reasons for this. One is technological, wherein technical teams are outsourced overseas. The assumption is that the enterprise will save a significant amount of money. The downside is that it—somewhat unexpectedly—loses in-house technology expertise. Thus, what you may be left with is middle-tier management that is suddenly expected to take ownership of a service, including the technology, which is something they neither want nor are able to take on. The accountability and responsibility in these circumstances are challenging because it implies understanding how your service works, how to detect problems, and how to fix them. You need to establish metrics to comprehend how your service operates, but very few of these individuals understand how to do that unless they were heavily involved in the service build. It really is like running a mini startup company within the enterprise. The service needs to be managed and requires continuous assessment of risks and performance so that improvement ideas can be integrated into a roadmap and budgets. Interestingly, the cost of most improvements is not significant; there is often no capital expenditure and a limited cost for improving procedures (SOPs), processes, etc. However, this requires knowledge, interest, and people who actively think about their service every day. They need to keep communicating with users, considering issues, incidents, and problems they encounter, and capturing all that information in a form that is easy to access, sort, and use for future planning.

And that brings me back to my initial point. I believe that enterprises - even strong technology enterprises - struggle to make cyber security work, to bring the bang for the buck. The main reason is the ability to combine two challenging aspects: fully owning internal functions with cyber and/or IT teams, and simultaneously understanding the strengths and limitations of third-party SaaS services and how to integrate them into their operating teams’ daily tasks.

One of the main features of security is that it's fairly easy to put all the structural requirements in with a proper design. But it's very hard to change existing applications and services once they are up and running and generating revenue. When there is any downtime or risk to operations, the application owner will have questions that need to be addressed by the cybersecurity teams. However, what is even harder is explaining these issues in a manner that the application owner can easily understand, including the risks involved and how they are mitigated and managed.

With all that said, if you add to the picture an external regulation that needs to be understood not only by the technology teams but also by the compliance and legal teams, you need firm foundations on which to build your decisions, manage risks, and understand your threat landscape.

There is no lack of consultants who will help their clients with security evaluations. Educating clients how to interpret those external regulations is much less common - mostly because of the liability for potential sanctions. As a result, there is vacuum filled with the good old FUD - fear, uncertainty, doubt - which causes knee jerk reactions to somehow remove perceived risk of non-compliance "now", without thinking about mid or long-term effects - in the cost, resources, and ... compliance.

Optimism v Reality

The reason I have become skeptical about any cybersecurity measures providing value to the company is the deteriorating in-house expertise regarding technology, the understanding of internal IT systems, and the disappearance of ownership. The latter is to some degree a result of the former.

People who have no knowledge of technology or how to operate it exist. Enterprises lack the talent that used to be embedded in internal technology teams. There is a need for the ability to consider the operating model at the time of design. It is important to extend the understanding of IT to include its impact on operations. We must learn how to optimize operations through automation and how to manage the handover of relevant aspects of a particular functionality to different teams, while keeping oversight within the team that built the entire complex system.

I have seen many instances where a new project was delivered and handed over, and it worked. However, I could easily see how it created another technological debt regarding long-term operation and maintenance—issues that you will not notice until 12, 24, or 36 months later.

So, do you want cybersecurity to become a part of your company's value proposition? There is no way, unless you get this whole process from inception to implementation, rollout, and maintenance under control of one team with one clear vision. If you start slicing and dicing the life cycle, you will end up with something that barely works, is limited in duration, and becomes a hidden bomb.

If ownership is defined at the beginning, you can avoid substantial support costs, where you, as the owner of a service, have to deal with problems created by gaps in the documentation, vague SOPs that result in incorrect use, and missing maintenance requirements. Any of these issues could potentially become significant cost or risk items, or both.

So, is there a way to still build secure infrastructure technology and allow your enterprise to benefit from it? Yes, but you need to find and empower strong individuals who are capable of delivering from start to finish.. If I pick some particular aspects I've come across recently - as examples, the first one is around the technology design. Use architects as a resource, not as decision-makers; they do not have an understanding of services, operations, or the technology life cycle.

Start any new project by learning about the problem, how it impacts different teams, and what the limitations and costs are. After all, all you want to build is something that is easier to use and that makes people’s lives better. If it's not the case, they will just keep doing things the old way, their objectives are to get things done. Architects can help you draw diagrams and write descriptions, but always test their suggestions with small demonstrations. PaaS platforms are so advanced these days that you can create demonstrations in a matter of minutes or hours and show where the architects made mistakes.

Split the delivery into phases and start with the core functionality - just like any start-up does. Once you have built the first version, show potential users how to use it, talk to them, work out difficult bits and adjust your delivery plan. Start building an easy-to-find, library of usage examples. Ideally go to the point where users that can not only read but copy&paste configuration/integration code. Remember:

Users are NOT interested in the beauty of your IT service, they just want to know how to use it.

This library of user manuals, copy-and-paste examples, and pointers to IM channels, where users can ask questions and get answers in a couple of minutes, has a massive impact on the long-term efficiency and cost of your service.

It also builds toward a centralized, fast, and efficient incident response. Things break; incidents will occur that require fixing. Especially for automations, the whole point of defining and establishing a service is to solve problems, not to produce weekly PowerPoint decks.

The more complicated the technology is, the more expensive it is to train the support staff. Ownership is key. If you don’t have centralized functions that can quickly react to and fix problems that were not addressed during the initial design, you’ll encounter significant issues.