BlinkOps Agentic Security Automation

I have several use cases rather than a single one. When we start engagements, it is often for the SOC team on the SOAR  side of the house. They want to automate processes and enrich data. When we started, because the main competitor was Palo Alto Cortex , the focus was on the SOAR  side of the house where people wanted to automate things or topics. For example, reducing access to a laptop or similar actions.

Nowadays, I see the question has shifted more toward how analysts can make better decisions. This involves enriching data coming from a SIEM  or even situations where there is no SIEM  solution in place, or cases where we do not want to go into the SIEM. For example, when CrowdStrike reports something on an endpoint, analysts want to see who the endpoint belongs to. Sometimes just switching off an endpoint might be worse than keeping an eye on it. The focus is on really getting better context for the analyst and then making informed decisions. That is the second large use case on the SOC side.

On the vulnerability management side, I also see significant use cases. With Tenable, in the past, everyone said to just open a ticket in ServiceNow . What happened was the CISO team opened 2,500 tickets per week in ServiceNow , the IT operation said they could never handle all these tickets and closed all of them immediately without fixing anything. With Blink Ops , I can get context around the vulnerabilities and make informed decisions. For example, maybe these issues all point back to one AD setting, and out of those 2,500 tickets, only 100 would be fixed just by changing one Active Directory setting. The other ones might not be exploitable, so there is no reason to fix them immediately. Maybe they can be pushed to a later stage. There are critical systems or OT systems that should not be reported into the IT stack but should be reported into the OT stack. Normally in OT, I can only isolate systems and am not allowed to change anything on the OT devices. The goal is really managing the workload of people and then trying to get things fixed, much like the Verizon fix-find-verify approach. If clients do not want to go with Horizon and want to keep their Qualys or their Tenable, they can use this solution and make outcomes actionable. It is not just a report anymore; it is really discrete actions or fix actions to get to a better stage.

I would say the most useful feature is the out-of-the-box integrations. Blink Ops  comes with, I think at the moment, 140 different APIs. It is really easy to build a workflow. Anyone can do it. There is a human interface or more or less a ChatGPT interface where I can say, okay, can you give me this and this topic from CrowdStrike? And based on this, I want to do something or enrich this data with this and this. If the result is still valid, I can also do calculations. It is more or less a human interface that fills a wizard. Is the workflow done 100 percent? No, it is not done 100 percent, but it is 80 percent. And then I already know the structure. I might see the options without reading documentation because the wizard will say, okay, so an option is delete the virus or quarantine the virus. I see all these options in the wizard, and I would say it helps improve or build workflows by about 70 percent, or provides a time improvement factor of two or three compared to normal development.

The other valuable thing is really that I do not need a developer because most companies said the problem for them in security is they see something they want to improve, and then they have to go back to the development team. In a bank, for example, all developers are developing the new online banking solution, so there are no developers available. There is a queue, and then HR says they need a piece of software. It is always hard because security teams tend not to have developers. Some SOC teams do, but everything outside the SOC does not have developers. For me, it is really the APIs and the natural language processing to build workflows that stand out.

Maybe the last valuable feature I have seen, and that is a new solution, is the case management. I can build cases because this was always a bit tricky in the beginning when Blink Ops did not have their own case management. I had to jump into a different case management and hold the data. Now I can keep the data within the platform and make informed decisions. This is especially useful if I want to use the solution for the agents. Blink Ops introduced agents a year ago, and I can have all the stored data and use it for the agents. An agent would not hallucinate, or I would say the answers of the agents since the questions are stricter. My feeling is I have never seen one hallucinating if it has been done right. That is the disclaimer. If I ask an open question, it might jump around like ChatGPT. But if I really use the information around it and give it the right context, then normally the decisions are quite good.

At the moment, I have no idea what an improvement can be because my feeling is Blink Ops can be deployed on-site in a hybrid mode or in the cloud. Hybrid mode means more or less the cloud environment running within the cloud. In Switzerland, I have seen quite a few clients where discussions happened and they said they do not want to go to cloud and want to run it on-premises. But the solution is just too big to run on-premises. Having a smaller version on-premises would be helpful, but my feeling is that is hard to achieve because the solution is just too big and too diverse to run on-premises.

The other thing is also the support model. Support models normally work if platforms are accessible from outside, but if I need to go within the company and do some modifications on the platform within the company, it is normally just time-consuming. This limits some of the use cases in some clients if they say, okay, we are a nuclear power plant and we do not want anyone coming from outside.

At the moment, nothing else comes to my mind because I would say Blink Ops is a comprehensive platform and sometimes I feel people are overwhelmed.

Maybe one thing I have had twice now, and I am not sure if this would be a Blink Ops topic or also one of the competitors. On CRM  platforms, if someone changes from one CRM  platform to the other CRM platform, there are always converters. From one music platform to the other music platform, there are converters. I think that is quite often missing. People struggle and said they had an automation platform or quite often they have seven or several automation platforms and say they want to reduce to, for example, two different platforms and want to get rid of the other ones. But then sometimes it is quite often a redevelopment, especially if it was a no-coding platform and everything is in code. Then normally it requires a huge transformation project. I think really helping the clients understand what the other platform does and then maybe on this level, just having the wizard would be fine. But my feeling is that migrating from one platform to the other is quite difficult.

I have been working with Blink Ops for close to two years.

I have not had any productive issues with Blink Ops.

What I have seen is that APIs change. Blink Ops has a team, so they have 400 integrations and they are checking on the integrations. But I know Microsoft might change something and will not report it back. All of a sudden, the method I used will not work and a use case or a workflow crashes because it does not get the data.

I would say that is the main issue which platforms have seen: the platforms change the API without prior warning. If there is a prior warning, normally I and my team always tell clients that they have to report or ask the people who own CrowdStrike or any other platform so they are aware of API changes. Blink Ops is also aware, and normally they report back. Quite often, the customer success team informs the client there is a new API coming or maybe a better API coming because it is more responsive or needs different parameters. They want to retire this API and would love to go to this next API. But as long as they run in parallel, it is not an issue. I would say if APIs get changed, that is probably the biggest issue on any automation.

I would say scalability is endless or close to endless. I have been working on a large tender for an international airline, and they wanted to use Blink Ops in their SOC. For me, I was a bit scared in the beginning that a solution scales up to this level. They said it is not a problem because it will just start one discrete platform after the other. Since the workflows are independent or even if I have a complex workflow with 10 or 20 steps, there is shared data in the case management. Everyone can use the shared database and using this, I can just scale up one platform after the other to get a better workload. This was highly appreciated by the airline when I had the discussion with them. I think they said they are looking for 15 million workflows in parallel that they want to execute.

For me, I would say that is unrealistic from a consultant perspective. Even if I have 50 million workflows and only 10 need an analyst, for example, it is still 1,500 workflows which require an analyst. An analyst, even if quite a lot of the pre-work has been done, at the end, if the decision is yes or no, the agent can do the decision or an automation can do the decision. But if I get some content or content and maybe some context, I need to read. There is no way to close a ticket within a minute. If it is a minute on a working day, with even eight hours, it is 60 workflows an hour times eight, so I would require still a thousand analysts, which is ridiculous.

For me, the technical solution is not a limit. The limit is more the people I have and are we doing the right things? Because also an automation should help people make things easier. But why would someone automate something which does not add any value? The platform is not a limit, and in the past, I have seen quite many platforms which are the limit. The other thing is maybe also the APIs to some platforms might be the limit because if someone starts opening a thousand tickets a minute in ServiceNow, maybe ServiceNow might crash or the API would not let them open a thousand tickets per minute. The same applies to CrowdStrike. If someone does too many queries, because the heavy lifting is also in other platforms. For me, automation is more or less a clever glue, but if the other systems are not stable enough, the glue will never make this system stable.

I would say Blink Ops has probably the best technical support of all my vendors. The reason is they want to understand the issues. Normally what they do is, if they are allowed by the client, they will go on the platform and really check on the platform. It is not that I am sending endless tickets or putting everything into a ticket. After three days, a service engineer says I do not understand or I have never seen this. They walk me through the platform, and either quite often they are already aware or when I said there is an issue, they said they have seen there is an issue because the platform has reported an issue. For example, if I cannot get any data from an API and it fails, they have seen this API fails or getting data on this API fails. The support team is always well-trained, understands the solution, and is helpful, really wanting to help the teams. In other companies, even customer success are less experienced than the support team of Blink Ops.

The first thing is the deployment of the platform, which is easy. Any deployment method is easy unless it is on-premises. Everything on cloud in the client's cloud or in Blink Ops cloud is an easy one. Then it is getting the API keys to the platforms or maybe building the first workflows. And then I have the workflows. Then it is important to get the API keys to the platforms or access to the platforms I want to interact with. Then I can take it from there and grow it from there. For me, it is really something where I might have value even already after a week.

The platform is there, even with some testing of the platform. The good thing is I would not say deploy a week and run it for the next five years and then start improving. I go back to the analysts, go back to the users and say this workflow, what would be helpful for you? Because adding a few steps is super easy. But I already have something in place and then I can improve, and this makes also a ROI discussion much easier.

If I start for example with Microsoft Sentinel , most clients said they developed something like nine months before they had the first workflow up and running in production. And then they are paying Microsoft, paying some developer resources. They already have three or four full-time equivalents on the bill and also Microsoft solution on the bill. Then it is much harder to come to an ROI.

Whereas I feel with Blink Ops, it is super easy if I have use cases. If I do not have use cases, the worst clients are the ones which do not have any idea what they want to automate. Companies which say they are looking for a strategic platform. Because then it can be everything or nothing. It is really hard to demonstrate the value.

Companies which have gone through the pain of having a different platform and understand the pain of the other platforms normally get it immediately, and for them, time to value or ROI is fully understandable and more or less a no-brainer.

Companies which have gone through the pain of having a different platform and understand the pain of the other platforms normally get it immediately, and for them, time to value or ROI is fully understandable and more or less a no-brainer.

I would say it is probably the easiest one I have ever seen. Is it always cheap? It is not cheap. The pricing in these platforms is always different. For example, if I have a look at Tines , and I just spoke to the Tines  team recently, they are not that strong in several areas, but they say they do have a free of charge license or a community license. They do have a basic license. The problem of this basic license is it only supports one group. The moment I need a bit of access control, I need to pay and sometimes I cannot just go from one level to the next, I need to go two levels. In the CRM, the price, the base price might be 10, the advanced price is 20, and the top is 40 already. So I am coming from 10 and going to 40 with the same workload, just by adding some security.

That is a good thing on Blink Ops. They calculate it based on actions and the pricing is really transparent. Calculations are based on actions and pricing is based on throughput on an agent.

I would say also on automation, there is a need to have the least privilege or a zero trust approach because the agent needs to be restricted. If I do projects, I use several ways. For example, the first way is if I ask for access to CrowdStrike and I only want to send read data, then I only ask for a read-only access in CrowdStrike, and maybe I also limit the topics which can be seen. That is the first one. The second one is also within the platform, I can always say who is allowed to change the workflow. Stages on a test environment might be more on a privileged environment or on a productive environment might be less.

Even in the workflows, I can say I am sending a message, I need access to this and this file or to this and this share until 9:00 tonight. My manager is not there or will not approve it. So someone else can approve for this manager if they do not answer within half an hour because immediate access to this platform is needed. Access control is on various levels, but also on the agent. I have not seen any platform which limits the access of an agent that much and has such granular auditing than Blink Ops has.

I would rate this solution a 9 out of 10.