Aggregator

You must login to view this content

I will be really, really honest with you — I have been totally “writer-blocked” (more “analyst blocked”, really) and I decided to release it anyway today … given the date. But I am taking a leap of faith here…

A bit of history first. So, my “SOC visibility triad” was released on August 4, 2015. It stated that to have good SOC visibility you need to monitor logs (L), endpoint (E) sources and network (N) sources. So, L+E+N was the original triad. Note that this covers monitoring mechanisms, not domains of security (more on this later; this matters!)

5 years later, in 2020, I revisited the triad, and after some agonizing thinking (shows at the above link), I kept it a triad. Not a quad, not a pentagram, not a freakin’ hex.

So, here in 2025, I am going to agonize much more .. and then make a call (hint: blog title has a spoiler!)

How do we change my triad?

First, should we …

Let’s look at whether the three original pillars should still be here in 2025. We are, of course, talking about endpoint visibility, network visibility and logs.

My 2020 analysis concluded that the triad is still very relevant, but potential for a fourth pillar is emerging. Before we commit to this possibly being a SOC visibility quad — that is, dangerously close to a quadrant — let’s check if any of the original pillars need to be removed.

Many organizations have evolved quite a bit since 2015 (duh!). At the same time, there are many organizations where IT processes seemingly have not evolved all that much since the 1990s (oops!).

First, I would venture a guess that, given that EDR business is booming, the endpoint visibility is still key to most security operations teams. A recent debate of Sysmon versus EDR is a reflection of that. Admittedly, EDR-centric SOCs peaked perhaps in 2020, and XDR fortunately died since that time, but endpoints still matter.

Similarly, while the importance of sniffing the traffic has been slowly decreasing due to encryption and bandwidth growth, cloud native environments and more distributed work, network monitoring (now officially called NDR) is still quite relevant at many companies. You may say that “tcpdump was created in 1988” and that “1980s are so over”, but people still sniff. Packets, that is.

The third pillar of the original triad — logs — needs no defense. Log analysis is very much a booming business and the arrival of modern IT infrastructure and practices, cloud DevOps and others have only bolstered the importance of logs (and of course their volume). A small nit appears here: are eBPF traces logs? Let’s defer this question, we don’t need this answer to reassert the dominance of logs for detection and response.

At this point, I consider the original three legs of a triad to be well defended. They are still relevant, even though it is very clear that for true cloud native environments, the role of E (endpoint) and N (network) has decreased in relative terms, while importance of logs increased (logs became more load bearing? Yes!)

Second, should we …

Now for the additions I’ve had a few recent discussions with people about this, and I’m happy to go through a few candidates.

First, let’s tackle cloud. There are some arguments that cloud represents a new visibility pillar. The arguments in favor include the fact that cloud environments are different and that cloud visibility is critical. However, to me, a strong counterpoint is that cloud visibility In many cases, is provided by endpoint, network, and logs, as well as a few things. We will touch these “few things” in a moment.

YES?

• Cloud native environments are different, they suppress E and N
• Cloud visibility is crucial
• Addresses unique cloud challenges
• Cloud context is different, even if E and N pillars are used for visibility
• CDR is a thing some say

NO?

• Cloud INCLUDES logs (lots, some say 3X in volume), and also E and N
• Too much overlap with other pillars (such as E and N)
• Cloud is a domain, not a mechanism for visibility.
• CDR is not a thing, perhaps

Verdict:

• NO, not a new pillar, part of triad already (via all other pillars)

The second candidate to be added is, of course, identity. Here we have a much stronger case that identity needs to be added as a pillar. So perhaps we would have an endpoint, network, logs and identity as our model. Let’s review some pros and cons for identity as a visibility pillar.

YES?

• Identity is key in the cloud; we observe a lot of things via IDP … logs (wait.. we already have a pillar called “logs”)
• By making identity a dedicated pillar, organizations can ensure that it receives the attention
• ITDR is a thing

NO?

• But identify visibility is in the logs … we already have logs!
• Too much overlap with other pillars (such as logs and E as well)
• ITDR is kinda a thing, but it is also not a thing

Verdict:

• Sorry, still a NO, but a weak NO. Identity is critical as context for logs, endpoint data and network telemetry, but it is not (on its own) a visibility mechanism.

Still, I don’t want to say that identity is merely just about logs, because “baby … bathwater.” Some of the emerging ITDR solutions are not simply relying on logs. I don’t think that identity is necessarily a new pillar, but there are strong arguments that perhaps it should be…

What do you think — should identity be a new visibility pillar?

Hold one, Anton, we need more data!

Here:

and

Now let’s tackle the final candidate, the one I considered in 2020 to be the fourth leg of a three legged stool. There is, of course, application visibility, powered by increased popularity of observability data, eBPF, etc. Application visibility is not really covered by endpoint orgs and definitely not by EDR observation. Similarly, application visibility is very hard to deduce from network traffic data.

YES?

• Application visibility is not covered by E and N well enough
• SaaS, cloud applications and — YES! — AI agents require deep application visibility.
• This enables deeper insights of the app guts, as well as business logic

NO?

• Is it just logs? Is it, though?
• Do organizations have to do application visibility (via ADR or whatever? Is this a MUST-HAVE but of 2030?
• Are many really ready for it in their SOCs?

Verdict:

• YES! I think to have a good 2025 SOC you must have the 4th pillar of application visibility.
• And, yes, many are not ready for it yet, but this is coming…

So, we have a winner. Anton’s SOC visibility QUAD of 2025

1. Logs
2. Endpoint
3. Network
4. Application

Are you ready? … Ready or not, HERE WE GO!

Related blogs:

• WhatDR or What Detection Domain Needs Its Own Tools?
• Revisiting the SOC Triad 2020
• Baby ASO: A Minimal Viable Transformation for Your SOC

SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025 appeared first on Security Boulevard.

India’s capital markets regulator, SEBI (the Securities and Exchange Board of India), has proposed a set of changes to its oversight of related-party transactions (RPTs), the often-sensitive financial dealings between companies and their affiliates. The changes would significantly raise the thresholds for which transactions must be disclosed or approved by shareholders, particularly for large corporations. […]

The post India’s Markets Regulator Wants to Ease Rules on Related-Party Deals. Here’s What That Means appeared first on Centraleyes.

The post India’s Markets Regulator Wants to Ease Rules on Related-Party Deals. Here’s What That Means appeared first on Security Boulevard.

Wilhelm Einhaus, a businessman from Bockum-Hövel, Germany, pioneered cell phone insurance services, establishing a robust network that integrated innovative offerings like a 24-hour repair and replacement program. His enterprise expanded rapidly, partnering with major telecommunications providers such as Deutsche Telekom and 1&1, and distributing products through over 5,000 retail outlets nationwide. At its zenith, the […]

The post Ransomware Hits Phone Repair & Insurance Firm, Causing Millions in Damage appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Key Takeaways The Disconnect Between Cyber Risk and Business Strategy If you’re wondering why risk assessments often feel disconnected from business strategy, you’re not alone. ISACA and PwC have both found that even in well-resourced organizations, critical gaps remain: This lack of operational clarity stems often from the absence of a structured, repeatable approach to […]

The post NIST Risk Assessment Template: A Step-by-Step Guide to Effective Risk Management appeared first on Centraleyes.

The post NIST Risk Assessment Template: A Step-by-Step Guide to Effective Risk Management appeared first on Security Boulevard.

Aug 04, 2025 - Lina Romero - 2025 is seeing an unprecedented surge of cyber attacks and breaches. AI, in particular, has introduced a whole new set of risks to the landscape and researchers are struggling to keep up. The OWASP Top 10 Risks for LLMs goes into detail about the ten most prevalent risks for AI, and today, we’re going to be covering number 5: Improper Output Handling. Improper Output handling can refer to a variety of ways that outputs are handled by LLMs before being passed onto other components, including insufficient validation or sanitization. Unlike Overreliance, which deals with overdependence on accuracy of LLM outputs, Improper Output Handling focuses on LLM-generated outputs specifically before they are passed on. Vulnerabilities caused by LLM05 can result in privilege escalation, remote code execution, cross-scripting, cross-site reference forgery, and more. Common Examples of Improper Output Handling Using an LLMs output to construct file paths without proper sanitization
Using LLM-generated content in email templates, potentially causing phishing attacks
Executing LLM-generated SQL queries without proper parameterization
Directly entering LLM output into a system shell or similar function, causing remote code execution Improper Output Handling is exacerbated by conditions such as: Applications grant LLMs too many privileges
Applications are vulnerable to Indirect Prompt Injection attacks (LLM01) which can lead to privilege escalation
3rd party extensions without enough checks to accurately validate inputs
Absence of output encoding
Lack of monitoring and logging for outputs
Insufficient rate limiting/ anomaly detection for LLMs Prevention and Mitigation Strategies In order to avoid Improper Output Handling, secure coding practices are essential. Be sure to do a validation of the output as a separate step, before passing the output off for further processing. Build in logic that handles failures or edge cases gracefully, to ensure that the application can continue to function, or re-engage the user input. Security teams should also be sure to follow OWASP’s Application Security Verification Standard guidelines (ASVS) and encode all model outputs. Teams should also employ context awareness, parameterized queries, and strict Content Security Policies to mitigate the risk of cross-scripting attacks. Lastly, as usual, robust logging and monitoring systems are essential for detecting unusual patterns in LLM outputs. Threats toward LLMs are on the rise, and security teams need to stay vigilant. FireTail is here to help simplify your AI security posture. See how it works by scheduling a demo, or get started with our free tier, today.

The post OWASP LLM Risk #5: Improper Output Handling – FireTail Blog appeared first on Security Boulevard.

Today, organizations increasingly rely on DevOps to accelerate software delivery, improve operational efficiency, and enhance business performance. According to RedGate, 74% have adopted DevOps, and according to Harvard Business Review Analytics, 77% of organizations currently depend on DevOps to deploy software and applications. However, as organizations embrace DevOps to accelerate innovation, the traditional approach of […]

The post How to Eliminate Deployment Bottlenecks Without Sacrificing Application Security appeared first on Blog.

The post How to Eliminate Deployment Bottlenecks Without Sacrificing Application Security appeared first on Security Boulevard.

Android partners and customers have experienced a temporary respite from double-digit vulnerabilities this summer. Google issued no security patches in its update last month.

The post Google addresses six vulnerabilities in August’s Android security update appeared first on CyberScoop.