Security headlines distract, but the threats keeping CISOs awake are fundamental gaps and software supply chain risks. Learn why basics and visibility matter most.
The post Sleepless in Security: What’s Actually Keeping CISOs Up at Night appeared first on Security Boulevard.
The Tea app breach highlights how weak back-end security can expose sensitive user data. Learn essential strategies for access control, data lifecycle management and third-party risk reduction.
The post Mobile App Platforms: Don’t Let Database Security Come Back to Bite You appeared first on Security Boulevard.
how JWTs secure AI agents and autonomous systems. Explore best practices for authenticating non-human identities using modern OAuth and token flows.
The post JWTs for AI Agents: Authenticating Non-Human Identities appeared first on Security Boulevard.
TLDR: Excessive Data Exposure (leaking internal data via API responses) is the silent, pervasive threat that is more dangerous than single dramatic flaws like SQL Injection. It amplifies every other API vulnerability (like BOLA) and happens everywhere because developers prioritize speed over explicit data filtering. Fixing it means systematically checking hundreds of endpoints for unneeded PII and sensitive internal data.
After writing about how API security is different from web app security – one thing that sticks is the idea that APIs can have hundreds of small issues that add up over time, rather than one big dramatic vulnerability.
Let me give you a concrete example of what I mean.
SQL injection is serious. Everyone knows that. But what about APIs that just… hand over sensitive data by design?
I’m not saying it’s worse than SQL injection. But it might be more insidious, because it amplifies every other vulnerability you have.
The patterns even encourage this and you can see it everywhere. You have an endpoint like GET /api/users/123 and it returns something like:
Login{
user_id: 42,
name: "Joviane",
email: "myemail@gmail.com",
role: "student"
}
{
internal_user_id: 64,
full_address: "Secure Street, 403",
ssn_last_4: 1234,
phone_number: "73737-7373"
}and a lot of stuff that you weren’t planning to expose. The frontend only displays name and email, but the API is returning EVERYTHING from the database.
You might think, “but only authenticated users can call this endpoint, so it’s fine!”. And yeah, that’s true. But what happens when an attacker compromises ANY user account? When a developer accidentally logs the full response? When a browser extension scrapes the data? When the response gets cached somewhere it shouldn’t be? All of that sensitive data is just sitting there, waiting.
The worst part? This compounded with other vulnerabilities. Say you have a BOLA vulnerability where users can access other users’ data by changing an ID. If your API only returned public fields, the impact would be limited. But if it’s leaking PII, internal IDs, or sensitive business data, now that BOLA just became a massive data breach waiting to happen.
Here’s the thing: this isn’t malicious. Usually, it’s convenient. Returning the whole object is faster than filtering fields. ORMs don’t help either, they return everything by default unless you explicitly use projection or select specific fields. Sometimes teams are trying to be clever and “future-proof” their APIs with fields they might need later. And sometimes? It’s just copy-paste. One endpoint did it this way, so all the others followed.
It makes sense from a development velocity perspective. I’ve done this myself when shipping features under pressure. You write a quick endpoint, test that the frontend displays correctly, and ship it. The API is returning 20 fields but the UI only uses 3? Nobody notices because it works.
Let me give you a concrete example I’ve seen play out in a code review. An e-learning platform had an endpoint GET /api/courses/{courseId}/students that returned student enrollment data. Makes sense for instructors to see their students, right? But it wasn’t just returning names and progress percentages. It was also returning full email addresses, enrollment dates, payment status, quiz attempt histories with timestamps, discussion forum activity metrics, and even device information from where students were accessing the course.
The frontend displayed student names and their course completion percentage. That’s it. And if you were a student? You could only see your own status in the UI. But any enrolled student could hit that endpoint directly, change the course ID, and pull data from other courses. Someone could iterate through course IDs and build a complete database of who’s taking what courses, payment patterns, learning behaviors, and personal contact information. They didn’t need to break anything or find some clever exploit. The API was just handing it all over.
Luckily, this got caught before production, but as the feature was working fine in the UI and the API, this could’ve easily slipped through and reached production.
And let’s talk about the PII implications here. That leaked student data? We’re talking full names, email addresses, phone numbers, physical addresses, potentially payment information. In a lot of jurisdictions, that’s a GDPR violation or equivalent waiting to happen. Even if the attacker never uses the data maliciously, you’ve just exposed yourself to regulatory fines, mandatory breach notifications, and a PR nightmare. All because the API returned 15 extra fields that nobody actually needed. The business intelligence leak is bad for competitive reasons, sure. But the PII exposure? That’s the kind of thing that gets you on the front page of technical channels for all the wrong reasons.
Another common pattern: pagination endpoints that leak way too much. You call GET /api/students?page=1&limit=100 expecting a list of students, and you get back not just the students, but also their hashed passwords, API keys, internal permissions, last login times, IP addresses… all stuff that should never leave the backend.
SQL injection is one vulnerability. You can find it, fix it and you are done. Excessive data exposure? That’s hundreds of endpoints, each leaking a little data, compounding over time.
Which one is easier for an attacker to exploit at scale? The one that exists in every single endpoint. They don’t need to find a clever injection payload. They just need to iterate through your API and collect everything you’re giving them for free. And because it’s “technically working as designed,” it might not even trigger your security monitoring. No failed requests, no suspicious payloads, just normal API calls returning way too much information.
There’s Mass Assignment – where a user sends {"name": "Deckan", "isAdmin": true} and the API just… accepts both fields. No validation on what should be updatable. Suddenly, regular users are admins. Or Improper Rate Limiting. No limits on password reset? Account takeover via brute force. No limits on OTP verification? Bye-bye 2FA. No limits on search? Congrats, someone just scraped your entire database.
And the classic: Predictable Resource IDs. /api/invoices/1001, /api/invoices/1002… you see where this is going. An attacker just iterates and collects everything. Classic BOLA.
These aren’t the sexy zero-day exploits that make headlines. They’re architectural problems baked into dozens or hundreds of endpoints. Finding them means actually understanding what each endpoint does. You need to know what each endpoint returns, what it needs to return, and what’s just extra baggage. Then multiply that by every endpoint in your API. It’s tedious, but it matters.
This is why API security testing is tricky. You’re not hunting for one big vulnerability. You’re checking every single endpoint for these patterns. Data leaking where it shouldn’t, auth checks that are missing, rate limits that don’t exist. All these problems are everywhere and they add on top of each other. At Detectify, our API scanning handles the tedious part, systematically checking every endpoint for vulnerabilities. That way your team can spend time on the stuff that actually needs human judgment, like business logic vulnerabilities and understanding your specific app’s security context.
And here’s the hard question that we’d love to hear about: when you’re building a new endpoint, how do you make sure developers only return the necessary fields? Code review? Automated checks? Response DTOs that force explicit field selection?
The post The API vulnerabilities nobody talks about: excessive data exposure appeared first on Blog Detectify.
Picture this: it’s 3 AM, and your message broker is acting up. Queue depths are climbing, consumers are dropping off, and your on-call engineer is frantically restarting pods in a Kubernetes cluster they barely understand. Sound familiar?
For years, we lived this reality with our self-hosted RabbitMQ running on EKS. Sure, we had “complete control” over our messaging infrastructure, but that control came with a hidden cost: becoming accidental RabbitMQ experts, a costly operational distraction from our core mission: accelerating the release of features that directly benefit our customers and help them keep their assets secure.
The breaking point came when we realized our message broker had become a single point of failure—not just technically, but organizationally. Only a handful of people could troubleshoot it, and with a mandatory Kubernetes upgrade looming, we knew it was time for a change.
Enter Amazon MQ: AWS’s managed RabbitMQ service that promised to abstract away the operational headaches.
But here’s the challenge: we couldn’t just flip a switch. We had over 50 services pumping business-critical messages through our queues 24/7. Payment processing, user notifications, data sync—the works. Losing a single message was unacceptable. One wrong move and we’d risk impacting our security platform’s reliability.
This is the story of how we carefully migrated our entire messaging infrastructure while maintaining zero downtime and absolute data integrity. It wasn’t simple, but the process yielded significant lessons in operational maturity.
Running your own RabbitMQ cluster feels empowering at first. You have complete control, can tweak every setting, and it’s “just another container” in your Kubernetes cluster. But that control comes with a price. When RabbitMQ starts acting up, someone on your team needs to know enough about clustering, memory management, and disk usage patterns to fix it. We found ourselves becoming accidental RabbitMQ experts when we really just wanted to send messages between services.
The bus factor was real. Only a handful of people felt comfortable diving into RabbitMQ issues. When those people were on vacation or busy with other projects, incidents would sit longer than they should. Every security patch meant carefully planning downtime windows. Every Kubernetes upgrade meant worrying about how it would affect our message broker. It was technical debt disguised as infrastructure.
The warning signs were there. Staging would occasionally have weird behavior—messages getting stuck, consumers dropping off, memory spikes that didn’t make sense. We’d restart the services and things would go back to normal, but you can only kick the can down the road for so long. When similar issues started appearing in production, even briefly, we knew we were on borrowed time.
Kubernetes doesn’t stand still, and neither should your clusters. But major version upgrades can be nerve-wracking when you have critical infrastructure running on top. The thought of our message broker potentially breaking during a Kubernetes upgrade—taking down half our platform in the process—was the final push we needed to look for alternatives.
With Amazon MQ, someone else worries about keeping RabbitMQ running. AWS handles the clustering, the backups, the failover scenarios you hope never happen but probably will. It’s still RabbitMQ under the hood, but wrapped in the kind of operational expertise that comes from running thousands of message brokers across the globe.
AWS takes care of many of the routine operational tasks, though you still need to plan maintenance windows for major upgrades. The difference is that these are less frequent and more predictable than the constant patching and troubleshooting we dealt with before. The monitoring becomes simpler too—you may still use Grafana panels, but now they pull from CloudWatch instead of requiring Prometheus exporters and custom metrics collection.
Amazon MQ isn’t serverless though, so you still need to choose the right instance size and monitor both CPU, RAM, and disk usage carefully. Since disk space is tied to your instance type, running out of space is still a real concern that requires monitoring and planning. The key difference is that you’re monitoring well-defined resources rather than debugging mysterious cluster behavior.
Security by default is always better than security by choice. Amazon MQ doesn’t give you the option to run insecure connections, which means you can’t accidentally deploy something with plaintext message traffic. It’s one less thing to worry about during security audits and one less way for sensitive data to leak.
When your message broker just works, developers can focus on the business logic that actually matters. You still get Slack alerts when things go wrong and queue configuration is still something you need to think about, but you’re no longer troubleshooting clustering issues or debugging why nodes can’t talk to each other at 2 AM. The platform shifts from something that breaks unexpectedly to something that fails predictably with proper monitoring.
Over 50 services depended on RabbitMQ:
Like many companies that have grown organically, our RabbitMQ usage had evolved into a complex web of dependencies. Fifty-plus services might not sound like a massive number in some contexts, but when each service potentially talks to multiple queues and many services interact with each other through messaging, the dependency graph becomes surprisingly intricate. Services that started simple had grown tentacles reaching into multiple queues. New features had been built on top of existing message flows. What looked like a straightforward “change the connection string” problem on paper turned into a careful choreography of moving pieces.
Messages were business-critical – downtime was not an option.
These weren’t just debug logs or nice-to-have notifications flowing through our queues. Payment processing, user notifications, data synchronization between systems—the kind of stuff that immediately breaks the user experience if it stops working. The pressure was real: migrate everything successfully or risk significant business impact.
Risks included:
Message systems have this nasty property where small problems can cascade quickly. A consumer that falls behind can cause queues to back up. A producer that starts sending to the wrong place can create ghost traffic that’s hard to trace. During a migration, you’re essentially rewiring the nervous system of your platform while it’s still running—there’s no room for “oops, let me try that again.”
We needed a plan to untangle dependencies and migrate traffic safely.
Service Mapping and Analysis
Before touching anything, we needed to understand what we were working with. This meant going through every service, every queue, every exchange, and drawing out the connections. Some were obvious—the email service clearly produces to the email queue. Others were surprising—why was the user service consuming from the analytics queue? Documentation helped, but sometimes the only way to be sure was reading code and checking configurations.
The RabbitMQ management API proved invaluable during this phase. We used it to query all the queues, exchanges, bindings, and connection details—basically everything we needed to get a complete picture of our messaging topology. This automated approach was much more reliable than trying to piece together information from scattered documentation and service configs.
Interactive topology chart showing service dependencies and message flows
With all this data, we created visual representations using go-echarts to generate interactive charts showing message flows and dependencies. We even fed the information to Figma AI to create clean visual maps of all the connections and queue relationships. Having these visual representations made it much easier to spot unexpected dependencies and plan our migration order.
Visual map of RabbitMQ connections and dependencies
The visualizations helped us identify both hotspots where many services converged, and “low hanging fruits”—services that weren’t dependent on many other components. By targeting these first, we could remove nodes from the dependency graph, which gradually un-nested the complexity and unlocked safer migration paths for upstream services. Each successful migration simplified the overall picture and reduced the risk for subsequent moves.
Service Categorization
This categorization became our migration strategy. Consumer-only services were the easiest—we could point them at the new broker without affecting upstream systems. Producer-only services were next—as long as consumers were already moved, producers could follow safely. The Consumer+Producer services were the trickiest and needed special handling.
Migration Roadmap
Having a plan beats winging it every time. We could see which services to migrate first, which ones to save for last, and where the potential problem areas were. It also helped with communication—instead of “we’re migrating RabbitMQ sometime soon,” we could say “we’re starting with the logging services this week, then the notification system the week after.”
Safety Net Strategy
Shovels became a critical part of our strategy from day one. These plugins can copy messages from one queue to another, even across different brokers, which meant we could ensure message continuity during the migration. Instead of trying to coordinate perfect timing between when producers stop sending to the old broker and consumers start reading from the new one, shovels would bridge that gap and guarantee no messages were lost in transit.
Export Configuration
We exported the complete configuration from our old RabbitMQ cluster, including:
RabbitMQ’s export feature became our best friend. Instead of manually recreating dozens of queues and exchanges, we could dump the entire configuration from the old cluster. This wasn’t just about saving time—it was about avoiding the subtle differences that could cause weird bugs later. Queue durability settings, exchange types, binding patterns—all the little details that are easy to get wrong when doing things by hand.
Mirror the Setup
We then imported everything into Amazon MQ to create an identical setup:
The goal was to make the new broker as close to a drop-in replacement as possible. Services shouldn’t need to know they’re talking to a different broker—same queue names, same exchange routing, same user accounts. This consistency was crucial for a smooth migration and made it easier to roll back if something went wrong.
Queue Type Optimization
We made one strategic change: most queues were upgraded to quorum queues for better durability, except for one high-traffic queue where quorum caused performance issues.
Quorum queues are RabbitMQ’s answer to the classic “what happens if the broker crashes mid-message” problem. They’re more durable but use more resources. For most of our queues, the trade-off made sense. But we had one queue that handled hundreds of messages per second, and the overhead of quorum consensus was too much. Sometimes the best technical solution isn’t the right solution for your specific constraints.
Once the new broker was ready, we began moving services live. But we didn’t start with production—we had the same setup mirrored in staging, which became our testing ground. For every service migration, we’d first execute the switch in staging to validate the process, then repeat the same steps in production once we were confident everything worked smoothly.
Consumer-only services were our practice round. We could move them over and if something went wrong, the blast radius was limited. The shovel plugin became our safety net—it copies messages from one queue to another, even across different brokers. This meant messages sent to the old queue while we were migrating would still reach consumers on the new broker. No lost messages, no service interruption.
Step 1: Switch consumer to Amazon MQ.
Step 2: Add shovel to forward messages from the EKS RabbitMQ Old Queue to the Amazon MQ New Queue.
Step 3: Consumers seamlessly read from Amazon MQ.
Once consumers were happily reading from Amazon MQ, we could focus on the producers. Since the queue and exchange names were identical, producers just needed a new connection string. Messages would flow into the same logical destinations, just hosted on different infrastructure.
Note: For a producer to be eligible for migration, you want all the downstream consumers to be migrated first.
Step 1: Switch producer to Amazon MQ.
Step 2: Messages flow to the same queues via the new exchange/broker.
Step 3: Remove shovel (cleanup).
Key principle: migrate downstream consumers first, then producers to avoid lost messages.
This principle saved us from a lot of potential headaches. If you move producers first, you risk having messages sent to a new broker that doesn’t have consumers yet. Move consumers first, and you can always use shovels or other mechanisms to ensure messages reach them, regardless of where producers are sending.
These services were the final boss of our migration. They couldn’t be treated as simple consumer-only or producer-only cases because they did both. Switching them all at once meant they’d start consuming from Amazon MQ before all the upstream producers had migrated, potentially missing messages. They’d also start producing to Amazon MQ before all the downstream consumers were ready.
The solution required a bit of code surgery. Instead of one RabbitMQ connection doing everything, these services needed separate connections for consuming and producing. This let us migrate the consumer and producer sides independently.
Step 1: Migrate consumer side to Amazon MQ (producer stays on old broker). The service now consumes from the new queue (via the shovel) but still produces to the old exchange.
Step 2: Switch producer side to Amazon MQ (full migration complete). Now both consuming and producing happen on Amazon MQ.
This gave us full control to migrate complex services step by step without downtime.
Old habits die hard, and one of those habits is checking dashboards when something feels off. We rebuilt our monitoring setup for Amazon MQ using Grafana panels that pull from CloudWatch instead of Prometheus. This simplified our metrics collection—no more custom exporters or scraping configurations. The metrics come directly from AWS, and we still get the same visual dashboards we’re used to, just with a cleaner data pipeline.
We focused on four key metrics that give us complete visibility into our message broker:
We set up a layered alerting approach focusing on the infrastructure level and service-specific monitoring:
Live migration is possible, but it’s not trivial and definitely requires careful planning.
We managed to avoid downtime during our migration, but it took some preparation and a lot of small, careful steps. The temptation is always to move fast and get it over with, but with message systems, you really can’t afford to break things. We had a few close calls where our planning saved us from potential issues.
Some approaches that made our migration smoother:
These aren’t revolutionary ideas, but they worked well in practice. The downstream-first approach felt scary at first but ended up reducing risk significantly. Having identical setups meant fewer surprises. Running both brokers in parallel gave us confidence and fallback options.
The migration went better than we expected:
The new system has been more stable, though we still get alerts and have to monitor things carefully. The main difference is that when something goes wrong, it’s usually clearer what the problem is and how to fix it. Less time spent digging through Kubernetes logs trying to figure out why rabbit are unhappy.
Moving from RabbitMQ on EKS to Amazon MQ turned out to be worth the effort, though it wasn’t a simple flip-the-switch operation.
The main win was reducing the operational burden on our team. We still have to monitor and maintain things, but the day-to-day firefighting around clustering issues and mysterious failures has mostly gone away.
If you’re thinking about a similar migration:
The migration itself was stressful, but the end result has been more time to focus on building features instead of babysitting infrastructure.
Looking back, the hardest part wasn’t the technical complexity—it was building confidence that we wouldn’t break anything important. But with good planning, visual dependency mapping, and a healthy respect for Murphy’s Law, it’s definitely doable.
Now when someone mentions “migrating critical infrastructure with zero downtime,” we don’t immediately think “impossible.” We think “challenging, but we’ve done it before.”
The post Migrating Critical Messaging from Self-Hosted RabbitMQ to Amazon MQ appeared first on Blog Detectify.
Two months since I joined Detectify and I’ve realized something: API security is a completely different game from web application security. And honestly? I think a lot of teams don’t see this yet.
Let’s look at the modern application. Your mobile app? APIs. Your crucial SaaS integrations? APIs. That complex checkout flow? Probably five or more API calls talking with each other. Modern applications are, fundamentally, just APIs talking to other APIs with a fancy UI layered on top.
But here’s what’s been catching me off guard: many companies don’t even have a complete inventory of their APIs. You’re trying to secure a perimeter you can’t even see the edges of. I have seen:
How can you secure what you can’t see?
When we talk about web vulnerabilities, usually we’re dealing with XSS, CSRF, clickjacking – stuff that messes with what users see or tricks them into clicking something they shouldn’t. API vulnerabilities are a different beast. We’re talking broken authentication, APIs exposing way too much data, weak rate limiting, injection attacks.
These attacks skip the UI entirely. An attacker doesn’t need to trick a user into clicking something malicious. They just need to understand your API contract and find the weak spots. That’s it. The scary part? They can automate all of this.
Web apps usually use session-based authentication with cookies. It’s pretty standard, most frameworks handle it well, and there are well-known patterns to follow. APIs? That’s where things get messy. OAuth, JWT, API keys, mutual TLS, custom bearer tokens… There are so many different approaches, and each one has its own vulnerability patterns. I’ve been diving deep into the OWASP API Security Top 10, and honestly, the auth issues are wild. Broken Object Level Authorization, Broken Function Level Authorization… these things have scary-long names, but they’re everywhere. Even though everyone knows about them, they still pop up in production all the time.
API attacks are growing at an alarming rate for several reasons:
This is exactly why we’re constantly enhancing our API Scanning capabilities at Detectify, because understanding these blind spots is the first step to fixing them.
We’d love to hear how other teams are tackling this complex problem.
Q: What is the primary difference between web application security and API security?
A: Web application security often focuses on user-facing vulnerabilities like XSS, while API security is concerned with flaws like broken authentication and weak access control that attackers can exploit by directly interacting with the API endpoints, bypassing the UI.
Q: What are Shadow and Zombie APIs?
A: Shadow APIs are old endpoints that are forgotten but still deployed, while Zombie APIs are test or staging endpoints that were never turned off, and both extend the attack surface without the organization’s knowledge.
Q: Why are API attacks easily automated?
A: API attacks are easily automated because APIs return structured data (like JSON or XML) that is much easier for a script or bot to parse and manipulate than the more complex and varied structure of HTML pages.
The post Why API security is different (and why it matters) appeared first on Blog Detectify.
Last Updated on December 2, 2025 by Narendra Sahoo
Getting PCI DSS compliant is like preparing for a big exam. You cannot just walk into it blind, you first need to prepare, check your weak areas, next fix them, and then only face the audit. If you are here today for the roadmap, I assume you are preparing for an audit now or sometime in the future, and I hope this PCI DSS 4.0 Readiness Roadmap helps you as your preparation guide. So, let’s get started!
The first mistake many companies make is they don’t know what is really in the PCI scope. So, start with an inventory.
This is one area where many organizations rely on pci dss compliance consultants to help them correctly identify what truly falls under cardholder data scope.
Write all this down in a spreadsheet. Mark which ones store, process, or transmit card data. This becomes your “scope map.”
Now take the PCI DSS 4.0 standard and see what applies to you. Some basics:
Example: If you’re running an e-commerce store on Magento and it connects to MySQL, check if your DB is encrypted and whether DB access logs are kept.
Real story: A retailer I advised had their POS terminals still running Windows XP. They were shocked when I said PCI won’t even allow XP as it’s unsupported.
PCI DSS is not just about tech. If your staff doesn’t know, they’ll break controls.
Example: A company using Zendesk for support had to train agents not to ask customers for card details over chat or email.
Auditors don’t just look for controls, they look for evidence.
Example: If you are using AWS, enable CloudTrail + GuardDuty to continuously monitor activity.
Before the official audit, test yourself.
Example: I’ve seen companies that have everything in place but fail because their staff can’t explain what’s implemented.
Finally, once you have covered all major gaps, bring in a QSA (like us at VISTA InfoSec). A QSA will validate and certify your compliance. But if you follow the above steps, the audit becomes smooth and you can avoid surprises.
We recently helped Vodafone Idea achieve PCI DSS 4.0 certification for their retail stores and payment channels. This was a large-scale environment, yet with the right PCI DSS 4.0 Readiness Roadmap (like the one above), compliance was achieved smoothly.
Remember, even the largest organizations can achieve PCI DSS 4.0 compliance if they start early, follow the roadmap step by step, and keep it practical.
Most businesses panic only when the audit date gets close. But PCI DSS doesn’t work that way. If you wait till then, it’s already too late.
So, start now. Even small steps today (like training your staff or fixing one gap) move you closer to compliance.
For more than 20 years, we at VISTA InfoSec have been helping businesses across fintech, telecom, cloud service providers, retail, and payment gateways achieve and maintain PCI DSS compliance. Our team of Qualified Security Assessors (QSAs) and technical experts works with companies of every size, whether it’s a start-up launching its first payment app or a large enterprise.
So, don’t wait! Book a free PCI DSS strategy call today to discuss your roadmap. You may also book a free one-time consultation with our qualified QSA.
The post PCI DSS 4.0 Readiness Roadmap: A Complete Audit Strategy for 2025 appeared first on Information Security Consulting Company - VISTA InfoSec.
**Disclaimer: The content of this blog post is for general information purposes only and is not legal advice. We are very passionate about cybersecurity rules and regulations and can provide insights into how Detectify’s tool can help fit legal requirements. However, Detectify is not a law firm and, as such, does not offer legal advice.**
Navigating the complex and ever-changing compliance landscape is difficult for many companies and organizations. With many regulations, selecting the appropriate security tooling that aligns with the compliance needs of your business becomes a significant challenge.
This article provides insights into how businesses across the EU can effectively navigate compliance hurdles and make informed decisions when choosing security tools, particularly emphasizing the role Detectify can play in these crucial processes.
The EU Directive on Security of Network and Information Systems (The NIS 2 Directive), and the EU Digital Operational Resilience Act (The DORA Regulation) are some of the latest requirements that may be causing concern for companies. DORA is in force since January 2025, while the deadline for EU Member States to implement the NIS 2 Directive passed in October 2024.
At Detectify, we aim to support our customers by offering insight into these specific requirements and, notably, how our offerings can support organizations in achieving DORA and NIS 2 compliance.
The NIS 2 Directive is an EU-wide cybersecurity legislation, intended to widen the number of organizations actively making cybersecurity efforts in the EU, and to increase the magnitude of those efforts, by putting requirements on the security of networks and information systems. As it is an EU Directive (and not a Regulation), it must be transposed through national legislation in order to apply in the Member States. The deadline for such transposition was October 18, 2024, however the majority of Member States are lagging behind.
On 7 May 2025 the EU Commission reminded 19 Member States to transpose the Directive into national legislation. This includes Sweden. In Sweden, the government released their proposal for a new cybersecurity law to implement NIS 2 on June 12th 2025. The proposed legislation is going to enter into force on January 15th 2026.NIS 2 replaces and modernizes the previous NIS 1 directive in an attempt to keep up with the evolving cybersecurity threat landscape, covering many new sectors and introducing stricter requirements. A quick comparison of the NIS 1 and NIS 2 directives shows that the latter covers 18 sectors, while the former covers 7. The NIS 1 directive is 30 pages long, while NIS 2 is 73 pages long, which is an indicator for the increased complexity of requirements. Many companies in Sweden and across the EU will need to acquaint themselves with NIS 2 and adopt a risk-based approach to their system’s security.
Non-compliance fines will be higher than previously, and similar to the levels in the GDPR, as they will be calculated based on global annual revenue.
The requirements in the NIS 2 Directive apply to entities in sectors which are vital for the economy, society, and which rely heavily on ICT, such as energy, transport, banking, financial market infrastructures, drinking water, healthcare and digital infrastructure, and certain digital service providers (“essential and important entities”). Both private and governmental entities in the above-mentioned sectors are covered by NIS 2. Public administration entities are in scope as well.
At Detectify, we’ve noticed significant parallels between specific industries, like the public sector, technology and digital services, which are the main focus of the NIS 2 Directive, and areas where Detectify’s tool excels. Our solution is specifically designed for sectors like these, which face issues like rapid digital innovation, leading to an increasingly large attack surface, and where there is need for secure cloud hosting while maintaining full visibility over the entire attack surface.
The Detectify advanced application security testing (AST) platform comprises two products: Surface Monitoring and Application Scanning. Surface Monitoring is key in discovering and mapping the customer attack surface by giving them a comprehensive view through continuous discovery and monitoring of all hosted Internet-facing assets. At the same time, Application Scanning provides deeper insights into custom-built applications and actual business-critical vulnerabilities with advanced crawling and fuzzing, delivering customized intelligent recommendations on what discovered assets warrant deep testing.
With Detectify’s platform, customers can apply appropriate technical measures to manage external risks from both known and unknown vulnerabilities that threaten their systems and digital services by mapping, identifying, and proactively managing risks before they materialize. Mapping your attack surface is the first step to understanding what is there from a risk management perspective.
In addition, the detailed vulnerability information and attack surface context provided by Detectify can be invaluable for understanding the scope, nature, and potential root causes of a security incident. This facilitates more accurate and timely reporting to authorities, as mandated by NIS 2’s stringent notification deadlines.
In today’s landscape, where cyber threats and attacks are part of day-to-day business and where many malicious players exist (small-scale players, professional black hats, and governmental players), the cyber security requirements posed on critical businesses and providers are a must.
– Cecilia Wik, Head of Legal, Detectify
In short, the NIS 2 directive poses requirements on the security of networks and information systems through incident reporting and risk management and, of course, a responsibility for Member States to oversee and coordinate actions under the Directive.
Member States can adopt stricter cybersecurity requirements in their national legislations, as the NIS 2 Directive is a minimum harmonization directive. As the Directive is still not fully adopted in most Member States, we may see territorial differences within the EU. They will most likely, however, be minor, and most national implementations will be very similar to the Directive.
NIS 2 Article 21.1 outlines that essential and important entities must take appropriate and proportionate technical, operational, and organizational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimize the impact of incidents on recipients of their services and on other services.
Furthermore, Article 21.2 sets out 10 different minimum requirements of such measures. Detectify can play a key role in the compliance work concerning several of these requirements:
Art. 21.2.a) Policies on risk analysis and information system security
The Policies on risk analysis mentioned in NIS 2 are meant to be put in practice. Effective risk analysis begins with a complete understanding of the assets one needs to protect. Detectify Surface Monitoring provides comprehensive asset discovery, offering visibility into “what you’re exposing online,” including potentially unknown or forgotten assets (shadow IT) and the technologies they run.17 This continuous discovery and inventory process is the foundational first step for any robust risk analysis.
Article 21.2.d) Supply Chain Security
While Detectify primarily focuses on scanning the customer’s own external attack surface, our scanning capabilities are vital for managing the customer’s side of supply chain interactions. It can identify vulnerabilities or misconfigurations on externally facing assets that, while owned by the customer, may interact with or be managed by third-party suppliers (e.g., a misconfigured cloud service provided by a vendor but exposed under the customer’s domain).
Article 21.2 e) Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosures
Detectify’s Surface Monitoring can scan the entire external infrastructure for a wide range of vulnerabilities, including misconfigurations, exposed sensitive files, known CVEs, and, critically, risks like subdomain takeovers. Our Application Scanning conducts in-depth vulnerability assessments of web applications. It supports authenticated testing (to find vulnerabilities behind login screens) and employs advanced fuzzing techniques to identify vulnerabilities.
As many Member States are behind with the implementation, organizations may think it’s best to sit back and relax, and await the final implementation in their respective Member States. Depending on the business and structure of the organization, that may, however, not be the best approach. The EU Commission can issue fines to Member States that are delayed with implementing Directives, which means the 19 governments of the Member States that have not yet implemented the NIS 2 directive, have incentives to make sure national legislation is put in place fast. For organizations, this may mean that implementation can go faster than expected, and the time to get everything in place can suddenly be short. Especially if your organization is big and complex, with long lead times for important decisions and transformations, it’s better to get started now (if you haven’t already). As stated above, there can be some national deviations in the form of stricter requirements, but generally speaking, most national legislation will be very similar to the NIS 2 Directive. As such, most organisations can start their compliance work by looking at the requirements described in the Directive, while awaiting national legislation.
An additional aspect to keep in mind is that, while 19 Member States do not have national legislation in place yet, there are Member States that made the deadline. If you aren’t situated in any one of those Member States, but your business means that you supply products or services to organisations in those Member States, you may risk losing business if you can’t keep up with the NIS 2 requirements. Your customers are to some part required to push forward the requirements on their suppliers (explicitly through article 21.2.d – supply chain security), most likely including your company. On the other hand, if you already have robust information security efforts compliant with NIS 2 in place, even though you – formally – yet don’t have to, you may be able to gain
While networks and information systems for a wide range of organizations are within the scope of NIS 2, EU Member States have their own national legislation concerning measures needed to protect national security. In Sweden, the Protective Security Act (Swedish: Säkerhetsskyddslagen) aims to protect the operations of entities of significance for Sweden’s national security. Such entities may hold sensitive information or carry out security-sensitive activities needing robust protection against terrorism, espionage, and sabotage
The Protective Security Act specifically requires entities to adopt preventive measures to protect the confidentiality, integrity, and accessibility of classified information, and to protect systems used to carry out security-sensitive activities from harmful impact.
NIS 2 and the Protective Security Act may overlap and be applied simultaneously in organizations that are covered by both, but the Protective Security Act has precedence based on the lex specialis principle.
Just as is the case with NIS 2 entities, entities covered by the Protective Security Act need to take action to make sure they can withstand threats, including cyber attacks. Continuous monitoring of attack surfaces can help entities covered by the Protective Security Act in those efforts. The same goes for similar national legislation in other EU Member States.
The aim of the DORA Regulation is to create a regulatory framework whereby financial firms, and – importantly – also certain ICT providers, such as cloud service providers, will have to make sure they can withstand, respond to, mitigate and recover from all types of ICT-related disruptions and cyber threats. The focus for financial firms is, in other words, shifting from not only traditional financial resilience, to resilience in a wider sense, including digital resilience.
DORA is a Regulation, which, as opposed to NIS 2 which is a Directive, came into direct effect in EU Member States on January 17, 2025. Member States may adopt additional legislation on the same matter, but national implementation is not required for DORA to come into effect. This means that financial sector entities has had to be compliant with the DORA Regulation for almost half a year. The rules have been further elaborated by the EU Commission, in the form of Regulatory Technical Standards (RTS), Implementing Technical Standards (ITS) and guidelines.
The DORA Regulation has a significant impact across the EU Member States. It covers over 22 000 companies within the Union, harmonizing the financial sector’s operational resilience. It does not only affect financial institutions but also third-party service providers providing critical services to such institutions, such as cloud service providers.
The DORA Regulation covers 5 central areas:
1) Governance and Risk Management
2) Incident Reporting
3) Testing of Digital Operational Resilience
4) Management of ICT Third-Party Risks
5) Information Sharing
Detectify can help strengthen the resilience of financial institutions and ICT service providers by:
We will continue to add updates to this post as we receive more information about regulations and their implications. As in the regulations above, Detectify emphasizes proactive cyber security and is passionate about helping its customers become more secure. In this article, we have covered only a handful of topical regulations that apply in the EU, and we know there are many more specific standards and regulations that may apply.
With Detectify’s Attack Surface Custom Policies, users can monitor for policy breaches as they occur in production. If a policy breach is detected, an alert is produced with helpful insights to help accelerate remediation.
Attack Surface Custom Policies leverage the complete coverage capabilities of Surface Monitoring to continuously monitor your external attack surface, ensuring your clearly-defined security policies are enforced, no matter the size of your attack surface. Many of our customers have built their own personalized compliance rules on their exposed web assets.
Are you interested in learning more about Detectify? Start a 2-week free trial or talk to our experts.
Q: What is the main difference between the NIS 2 Directive and DORA?
A: The NIS 2 Directive sets a broad cybersecurity baseline for many critical sectors across the EU. DORA, in contrast, is focusing specifically on the digital operational resilience of the financial sector and its key technology suppliers.
Q: My organization is not in the financial sector. Do I still need to worry about DORA?
A: Not directly. However, if you are an ICT provider (e.g., a cloud service) for a financial institution, you will fall under the scope of DORA and must comply with its requirements.
Q: What is the first step to take for NIS 2 compliance?
A: A foundational first step is to conduct a thorough risk analysis, which begins with understanding your complete external attack surface. This involves discovering all internet-facing assets, including forgotten or unknown ones (shadow IT), to identify potential vulnerabilities.
This article was originally published in March 2024 and updated in June 2025
The post EU Regulating InfoSec: How Detectify helps achieving NIS 2 and DORA compliance appeared first on Blog Detectify.
“You can’t secure what you don’t know exists.” It’s a common refrain in cybersecurity (and for good reason!). But the reality is a bit more complex: it’s not enough to just know that something exists. To effectively secure your assets, you need to understand what each of them is. Without proper classification, applying the right security processes or tools becomes a guessing game.
There’s a discrepancy between what you think you’re exposing and what you actually are exposing. Critically, an attacker only cares about what is actually accessible to them, not what you think it is. Research from Detectify indicates that the average organization is missing testing 9 out of 10 of its complex web apps that are potential attack targets.
Imagine you’ve identified a few thousand assets exposed to the internet. The crucial next step is to determine what you are actually exposing. Different tools can help depending on what’s on your attack surface, but instead of focusing on specific tools right away, let’s concentrate on the methods and data points used to understand what each asset is.
Numerous data points can be used for classification. Let’s examine them in the order of a typical connection flow, assuming an outside-in, black-box analysis perspective. Internal network data or based on source code would require a different approach.
Asset classification methods covered in this guide
The data available for deeper classification heavily depends on the protocol encountered. For this blog post, we’ll focus primarily on HTTP, the backbone of web applications.
Key HTTP data points include:
If the response is HTML, we can delve even deeper:
If we haven’t gone down the HTTP and HTML path (e.g., we’ve encountered an SSH or SMTP server), we would then look further into the binary response or protocol-specific handshake data to understand what software components are running. However, that’s a topic for another article.
When we examine each data point individually, significant opportunities for fingerprinting and understanding exposed assets emerge. Combining them provides even richer insights:
Tools and Techniques: Manual inspection can be done with the dig command and basic human pattern recognition for small-scale analysis. For larger-scale testing, open-source tools like MassDNS can be highly effective.
Tools and Techniques: Nmap is a widely used tool for IP and port scanning. Alternatives for large-scale scanning include Zmap and MASSCAN. Whois lookups (command-line or web-based) are essential for ASN information.
Understanding which ports are open can help determine the firewall in place and the underlying systems running.
Tools and Techniques: For scanning at scale, masscan is fast, though it may produce a higher number of false positives. You’ll need to decide between speed and accuracy, as they often involve trade-offs. Nmap offers more accuracy and service detection features.
The identified protocol/schema is connected to the combination of hostname (e.g., the Host header for domain fronting, or TLS-based routing using SNI), IP address, and port in the request.
Tools and Techniques: Nmap is the most known service. Other tools like JA4T (for TLS client/server fingerprinting) and fingerprintx can also help identify protocols and services.
Tools and Techniques: JARM fingerprinting tools actively probe servers. Certificate Transparency (CT) logs are valuable public data sources for discovering issued certificates for domains, like crt.sh.
A simple 200 OK status code might offer limited information in isolation. However, observing an application’s status codes in response to crafted payloads can be far more revealing. Different payloads will trigger different behaviors, and a WAF may interfere. Additionally, response codes can vary based on the user-agent and accept-header.
$ curl -v http://whitehouse.gov * Trying 192.0.66.51:80... * Connected to whitehouse.gov (192.0.66.51) port 80 (#0) > GET / HTTP/1.1 > Host: whitehouse.gov > User-Agent: curl/7.81.0 > Accept: / > * Mark bundle as not supporting multiuse < HTTP/1.1 301 Moved Permanently < Server: nginx < Date: Wed, 16 Apr 2025 12:15:21 GMT < Content-Type: text/html < Content-Length: 162 < Connection: keep-alive < Location: https://whitehouse.gov/ < <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html>
The response body of the redirect clearly states that nginx is used.
Tools and Techniques: Common web scanning tools like Burp Suite, combined with human ingenuity, can help us understand more.
For example, sometimes triggering a non 200 status code might expose more information about a system or an underlying technology. As an example, if you’re looking to identify assets running IBM Notes/IBM Domino it can be helpful to request an nsf-file that does not exist.
Sending a GET request to example.com/foo.nsf can trigger a 404 response containing strings such as <h1>Error 404</h1>HTTP Web Server: IBM Notes Exception - File does not exist</body>.However, simply sending a request to a non-existing path such as example.com/foo will not trigger the same descriptive error.
This category is vast, so we’ll focus on key areas:
$ curl -Iks https://www.paypal.com/se/home | grep -Eo '.{16}salesforce.{16}' e.com https://.salesforce.com https://.f l.com https://*.salesforce.com https://sec
Many file types can be identified by the first few bytes of the file.
Tools and Techniques: The file command and other command like xxd or hexdump can be used to inspect these bytes.
Content-Type and Length
The combination of the Content-Type header and Content-Length can indicate application types:
Tools and Techniques: curl is useful here.
With libraries of known favicons (or their hashes), this can be a very fast way to scan a large number of assets. Running favicon fingerprinting across broad domain sets can yield significant insights into the technologies used.
Tools and Techniques: Tools like httpx -favicon or platforms like Shodan (which has a favicon hash search) can automate this.
The structure of URLs can be very revealing. The most basic example is the existence of an admin page at a specific path (e.g., /wp-admin for WordPress). Other examples are how product categories or user profiles are represented (e.g., /product/{id}, /user/{username}), the encoding used in parameters and the presence of directory listings.
Tools and Techniques: Wordlists of common paths can be sent with tools like Burp Intruder, ffuf, or dirsearch. Regex patterns can then be applied to the response data to identify interesting results.
<meta name="generator" content="WordPress 6.2.2" /> <meta id="shopify-digital-wallet" ...> <meta name="shopify-checkout-api-token" ...>
Tools and Techniques: These tricks are often hidden within tools and are typically opaque. Any DAST tool would fit into this category; Nuclei, for example, has open-source signatures for these purposes. Tools like Wappalyzer and WhatWeb could also be included, as they utilize similar techniques.
The structure and patterns in form tags, especially for logins, along with their action URLs, can provide strong clues about the underlying CMS.
Tools and Techniques: Some tools that can be used are Wappalyzer, WhatWeb, curl+grep.
Looking at code patterns involves identifying characteristic snippets, function names, variable naming conventions, CSS class structures, or HTML element arrangements typical of certain frameworks or libraries.
When analyzing code patterns, we are increasingly using statistical and linguistic models to match identified applications with known examples. One approach is to examine the linguistic structure of the code and remove all plain text content. However, this process becomes more challenging when the code is obfuscated or compressed.
Tools and Techniques: BishopFox has utilized bindings for Tree-sitter to parse the abstract syntax tree (AST) of JavaScript. Detectify co-founder and security researcher Fredrik Almroth has explored ANTLR for similar purposes, specifically aiming to parse GraphQL. Some useful links are https://tree-sitter.github.io/tree-sitter/ and https://www.antlr.org/. Comparing tree structures after obtaining an AST involves a relatively advanced field of mathematics.
It’s not uncommon for CMSs, themes, or plugins to include default links to their documentation or license agreement. For example:
<a href="https://www.espocrm.com" title="Powered by EspoCRM" Powered by <a href="http://ofbiz.apache.org" href="https://about.gitea.com">Powered by Gitea
Applications frequently load third-party resources, and both the type and location of these resources can provide insights about the application itself. This information can reveal details about any supply chain dependencies or technical components being utilized. For instance, the presence of an analytics platform (such as Amplitude) typically suggests that the application is of significant importance and is actively being developed.
Tools and Techniques: Wappalyzer provides this information, highlighting unique properties that may exist in external JavaScript, such as those hosted on CloudFront, which is a great source for links, domains, API operations, and more. Occasionally, these JavaScript files might contain sensitive information. Some interesting links to bookmark are TruffleHog and KeyHags.
While individual data points are helpful, their true power is unlocked when combined. Only then can we answer more elaborate and critical questions about our attack surface. One might envision an AI agent piecing this together, but a more standard approach involves defining the question and then selecting the appropriate data points and tools needed.
Some questions might require only a single data point, while others necessitate combining many to achieve an acceptable confidence level in the classification. Consider these:
Systematically collecting and analyzing these diverse data points can help security teams move beyond simple asset discovery to a much deeper understanding, classification, and potentially testing of their web applications. Some tools can automate asset classification and deliver intelligent recommendations on what assets are potential attack targets and warrant deep testing.
Are you interested in learning more about Detectify? Start a 2-week free trial or talk to our experts.
If you are a Detectify customer already, don’t miss the What’s New page for the latest product updates, improvements, and new vulnerability tests.
The post A practitioner’s guide to classifying every asset in your attack surface appeared first on Blog Detectify.
If you are a mature organization, you might manage an external IP block of 65,000 IP addresses (equivalent to a /16 network). In contrast, very large organizations like Apple may handle an astonishing 16.7 million IP addresses or more (about a /8 network). However, this isn’t the case for many of us. IP addresses are fixed assets and can be costly, so most modern organizations do not have a large number of directly assigned IP addresses for every service they expose to the internet.
Instead, it’s common to configure exposure through the Domain Name System (DNS). It’s not uncommon for an organization to have over 100,000 DNS records. While changes to firewall rules are often tightly regulated through Information Security Management System (ISMS) processes, modifications to DNS records are usually made with much less oversight. For instance, development teams might update DNS records directly using infrastructure as code via Terraform or similar It’s important to manage your DNS carefully, as numerous risks can arise from inadequate control.
Even if you believe you have full control over your DNS, there are still many risks that can crop up along the path from the DNS Root to the actual software lookup.
A basic DNS lookup involves several key components that work together to complete the final query:
DNS was originally built for a different time, when only a small number of computers were connected over a network built on trust. The same applies to many other protocols still in use today, including SMTP and BGP.
Since its original implementation, there have been several enhancements, such as DNSSEC, which help improve technical security. DNSSEC adds cryptographic signatures to existing DNS records to ensure their authenticity.
However, DNS management often remains a manual process, leading to issues that can arise from simple typos. Compounding the problem is the fact that many types of DNS-related vulnerabilities cannot be detected from within the network or tested in a staging environment.
Establishing communication begins with a DNS lookup. While information may be cached locally, if not, the following steps will be involved.
Many components within the DNS chain can break and are difficult to detect. When dealing with more than a few hundred DNS entries, automation becomes a need. The severity of DNS-related vulnerabilities can vary significantly, ranging from merely informational to highly critical. Traditional vulnerability management systems often overlook these types of misconfiguration vulnerabilities.
Subdomain takeovers are highly contextual; if you cannot compromise other systems or directly access user data (such as cookies) through your takeover, they are typically not considered severe. However, if you control one out of many Name Server (NS) delegations for the root (apex) zone, the situation is arguably worse than the most severe form of SQL injection. Over time, this could give you access to all traffic destined for the vulnerable domain, including its subdomains.
Automation is crucial for managing these risks as your attack surface expands. Learn how Detectify can help. Start a 2-week free trial or talk to our experts.
If you are a Detectify customer already, don’t miss the What’s New page for the latest product updates, improvements, and new vulnerability tests.
The post DNS is the center of the modern attack surface – are you protecting all levels? appeared first on Blog Detectify.
The traditional perception of security within an organization is as a barrier rather than a facilitator, imposing approval processes and regulations that inevitably slow down operations. In this blog post, along with our friends at Knowit Experience, we explore how a new mindset keeps growing. One that embraces security as an enabler and a business value contributor.
Organizations’ security departments have traditionally operated as a barrier rather than a facilitator, imposing lengthy processes and controls that required other teams to navigate complex approval systems. This would often lead to inevitable sighs and eye-rollings when someone mentioned the word “security”. Times have changed – we’re now in a climate where agility is crucial and the slightest bureaucracy can significantly hinder innovation and efficiency. Employees know this, and to avoid being faced with red tape they might find workarounds, ultimately undermining the whole original purpose of security.
There’s a focus on delivering customer value faster and more efficiently than ever before. Consequently, the vast majority of organizations have adopted frequent code releases to production, with SaaS companies leading the pack by pushing new releases at least weekly. Where does this leave security? If not properly integrated, organizations will either fail to move at the required pace or have to sacrifice their security posture.
To shift the narrative, it is essential for security teams to adopt the role of enablers rather than gatekeepers. But what does that exactly mean?
It’s a reality that each organization has its own security workflows and criteria for what is an acceptable risk in its business context. Not everything is an outright vulnerability. The challenge for many security teams is how to ensure that every team adheres to these internal policies. This is a daunting task, especially as the organization’s attack surface gets bigger and more complex.
Let’s picture a realistic scenario in which an organization’s security teams act as enablers rather than gatekeepers: teams across the organization are constantly adding new assets and technologies without the security team being aware. Despite this, the security team is still accountable for ensuring these assets are secured.
This lack of visibility would create many internal policy breaches that can go unnoticed for months, or even years. However, today, these teams have the option of proactively monitoring their attack surface and setting up their own custom policies to be alerted as soon as an asset does not comply.
In a world where security is focused on proactive monitoring rather than requiring upfront approvals for every action, organizations can monitor potential risks in real-time without interrupting workflows. Security becomes a protective force that supports operational efficiency.
With that said, we know that security teams should act as enablers. But it doesn’t end there. This mindset should extend throughout the entire organization. Everyone should adopt a security-first approach. When security teams work to support rather than hinder progress, and when developers and other teams are empowered to build securely from the outset, organizations can operate at the necessary pace while maintaining safety.
Security should not be an afterthought but rather a core component of the development cycle. By embedding good practices within developers’ daily routines, organizations can create seamless flows that protect assets without causing disruption.
A security-as-enabler approach allows for faster and safer operations and provides organizations with added business value, including increased customer trust, enhanced brand reputation, continuous business operations, and easier navigation of the current compliance landscape.
To gain a clearer understanding of how organizations are evolving to the notion of security as an enabler, we have the opportunity to consult with Dennis Adolfi – Head of Tech at Knowit Experience, a global IT agency that assists organizations in succeeding with their digital transformation efforts.
What’s your take on the meaning of being an enabler?
Being an “enabler” means creating conditions that empower an organization to explore new solutions—such as AI—without being paralyzed by fear of unknown threats. By establishing strong security processes and strategies, teams can manage risks continuously instead of shutting down innovative initiatives prematurely. In other words, a solid security posture can actually foster a culture of innovation rather than hindering it.
What common mistakes do companies make that prevent security from acting as an enabler for their organization? What should they be doing?
One major mistake is treating security solely as an IT issue. When security is labeled to a specific department, organizations lose the holistic perspective needed to protect their entire business. The most successful organizations we work with view security as a shared responsibility, where different teams collaborate and integrate security considerations from the earliest stage in the development cycle (“shift left”).
What trends will likely have an impact on organizations’ security strategy and operations?
AI and other non-deterministic systems are becoming increasingly central, making it harder to anticipate and circle the attack surface. This calls for a more structured approach to threat analysis—such as Threat Modeling and frameworks like the NIST AI RMF—and for tools capable of identifying unexpected vulnerabilities in real time, such as Detectify. By combining a broad, inclusive approach to security, a collective sense of responsibility, and systematic methods for threat analysis, organizations can both increase their capacity for innovation and maintain a strong security posture.
It is no wonder that the key to effective security in the modern organization is to shift its perception from a blocker to an enabler. Only when security is seen as a facilitator of progress, rather than an impediment, will it truly be embraced and effective.
“Security needs to be pragmatic, it needs to be seen as a business enabler not as a blocker to be taken seriously. However, pragmatism does not mean undermining the importance of security.” Photobox case study, the story of a company that succeeded at transforming security as an enabler for faster product development.
Are you interested in learning more about Detectify? Start a 2-week free trial or talk to our experts.
If you are a Detectify customer already, don’t miss the What’s New page for the latest product updates, improvements, and new vulnerability tests.
The post Making security a business value enabler, not a gatekeeper appeared first on Blog Detectify.
When was the last time you checked DNS configurations for subdomains pointing at services not in use? According to Crowdsource ethical hacker Thomas Chauchefoin, while expired and forgotten subdomains can easily become an entry point for an attacker to steal sensitive data and launch phishing campaigns, having the right tool in place can keep them at bay.
It’s no secret that with increasing third-party services and more subdomains, comes a larger attack surface, therefore a higher risk of potential cyber threats. The basic premise of a subdomain takeover is a host that points to a particular service (e.g. GitHub pages, Heroku, Desk, etc) not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service. As a hacker and a security analyst, Chauchefoin who has dealt with this type of issue, reveals how it can be risky for your business.
Subdomain takeover was pioneered by ethical hacker Frans Rosén and popularized by Detectify in a blog post back in 2014. Many years on, it has continued to build on the technology. However, it remains an overlooked and widespread vulnerability. Even companies that claim to prioritize security, such as Sony, Slack, Snapchat, and Uber, have been victims of subdomain takeovers.
Moreover, Microsoft, too, struggled with managing its thousands of subdomains, many of which were hijacked and used against users, its employees, or for showing spam content. Its subdomains are vulnerable to basic misconfigurations in their respective DNS entries. Chauchefoin adds that these issues remain either unfixed or unknown as subdomain takeovers might not be part of the company’s bug bounty program. The main reason is, he says, that most companies have poor DNS hygiene, which then opens the door to all kinds of abuse that can then be part of larger and more dangerous attack campaigns on your organization and its stakeholders.
Subdomains are not limited to the attack surface an organization has direct control – such as internal domains and apps you build – but also external attackable points. A subdomain takeover can be particularly problematic because subdomains aren’t always closely guarded assets, which means they can go undetected for some time.
If left unmonitored for vulnerabilities and misconfigurations, you can run into the risk of being unaware of what’s happening to your company’s subdomains resulting in a malicious actor taking control. Once attackers have access to the subdomain’s name servers or registrar account credentials, they can get another entity with access to modify delegation records so the subdomains point toward their own nameservers rather than the originals. It’s already too late to recover.
These breaches ultimately lead to data loss, brand reputation damage, and stolen customer data for the enterprise.
Many companies have subdomains pointing to applications hosted by third parties that lack proper security practices. Don’t be one of them
There are many ways cybercriminals could exploit unmonitored subdomains to steal information or deface sites. Malicious hackers are finding it easier to take over or exploit the vulnerabilities in the third-party assets within the enterprise’s ecosystem to carry out attacks such as malicious code injection, DNS hijacks or abusing the branded assets of an enterprise. In many instances, password managers automatically fill out login forms on subdomains belonging to the main application. As Chauchefoin recalls, “I still remember that the password manager LastPass used to auto-fill passwords even on subdomains, which could be dangerous in the case of targeted attacks.”
A subdomain takeover attack is a type of attack in which an attacker successfully seizes control over the subdomain in a hijacked DNS. When a DNS record points to a resource that isn’t available, the record itself should be removed from your DNS zone. If it hasn’t been deleted, it’s a “dangling DNS” record and creates the possibility for subdomain takeover. An attacker can leverage that subdomain to perform attacks like setting up phishing forms.
The most common situation is when a dangling record points to an expired online asset. By creating an account on this platform and claiming this subdomain, the attacker can deploy arbitrary content on it. It could help them to perform further attacks such as having an impact on primary domains pointing to resources on the one that was just taken over. “It’s also common to point to IP ranges like EC2 or OVH, where attackers could try to rent multiple servers and get the same IP as the previously used if they are lucky enough,” Chauchefoin says.
Detailing on the process, Chauchefoin proclaims that a subdomain takeover is rather easy to accomplish. It simply entails creating an account on a platform and claiming the subdomain.
Let’s assume that domain.com – a site owned by you – is the target and has a subdomain helpdesk.domain.com linked to a Support Ticketing-service. While enumerating all of the subdomains belonging to domain.com, the attacker who stumbles across helpdesk.domain.com, can find out where it belongs by reviewing the subdomain’s DNS records and could potentially take it over if it was abandoned. If an attacker were to take ownership of helpdesk.domain.com, they could build a convincing clone of an official support website, or even of domain.com. Then, by using spear phishing techniques or waiting for victims to fall in the trap via search engines, they could steal sensitive information from them. It would be practically impossible for users to know that they just arrived on a fake, attacker-controller website as the domain name is legit.
Attackers could then push malware, host static resources under this subdomain or expose services, which could then establish a proxy making helpdesk look like domain.com while intercepting the traffic when anyone visits helpdesk.domain.com.
Chauchefoin points out that when trying to take over a subdomain, the most common workflow for a hacker is to start with extensive “reconnaissance” to discover existing DNS records. “After the reconnaissance phase, hackers will try to look for any anomaly in the DNS records and probe the exposed services to look for errors which indicate that it is a dangling domain,” he says. Hunters often rely on services that were not originally intended for that use. For instance, Certificate Transparency databases – the open framework for monitoring SSL Certificates – contain millions of entries and are a gold mine, he adds. In many cases, attackers may be able to obtain and install a valid TLS certificate for the vulnerable subdomain to serve their phishing site over HTTPS. Other active techniques involve brute-forcing subdomains based on lists of most common values, naming conventions and permutations. This is where the hacker iterates through a wordlist and based on the response can determine whether or not the host is valid.
Another way to do it would be to compromise the target’s DNS servers or even the registrar to change the DNS records associated with the targeted domain. While this method is less common, Detectify co-founder and security researcher Fredrik Nordberg Almroth did it with the .cd ccTLD where he claimed the expiring name server for the Democratic Republic of Congo’s top-level domain before it was going to enter into deletion status.
Hackers can also execute second-order subdomain takeovers where vulnerable subdomains which do not necessarily belong to the target are used to serve content on the target’s website. This means that a resource gets imported on the target page, for example, via JavaScript and the hacker can claim the subdomain from which the resource is being imported. More on this, soon to follow.
An attacker can make use of stale DNS records to own the AWS S3 bucket or point to your subdomain, there is no longer a use by your organization. Therefore, it can be used to target your users, leak their account details via XSS and phish pages hosted on your companies’ domains. In many cases, an attacker can easily steal a victim user’s cookies and credentials via XSS if they are allowed on the subdomain.
In addition to serving malicious content to users, attackers can potentially intercept internal emails, mount clickjacking attacks, hijack users’ sessions by abusing OAuth whitelisting and abuse cross-origin resource sharing (CORS) to harvest sensitive information from authenticated users.
Seemingly a subdomain takeover can be dangerous, Chauchefoin says that a subdomain takeover may pose a relatively minor threat in itself and is generally part of a bigger picture or attack. However, when combined with other seemingly minor security misconfigurations, it may allow an attacker to cause greater damage.
…larger enterprises face a bigger risk as they can have thousands of subdomains
The impact of a subdomain takeover depends on the nature of the third-party service that the vulnerable subdomain points to. The need to keep a track of all subdomains are not limited to companies transitioning to the cloud.
Chauchefoin says that company executives forgetting about created subdomains is increasingly common. Consequently, it is vital for any Blue Team to be able to identify any change or vulnerability on external assets. “An up-to-date map of public-facing services helps in taking accurate decisions when it comes to removing the legacy ones to reduce the overall attack surface,” he continues.
Of course, subdomain takeover is a risk for any company irrespective of the industry, however, Chauchefoin believes that larger enterprises face a bigger risk as they can have thousands of subdomains. For instance,some time ago The Register reported that subdomains of Chevron, 3M, Warner Brothers, Honeywell, and many other large organizations were hijacked by hackers who redirected visitors to sites featuring porn, malware and online gambling.
Many companies have subdomains pointing to applications hosted by third parties that lack proper security practices. Don’t be one of them. When determining plausible attack scenarios with a misconfigured subdomain – more so after an attacker controls it – it is crucial to understand how the subdomain interacts with the base name and the target’s core service and how these subdomains are used in applications within your infrastructure.
Detecting that a subdomain takeover is being actively exploited is difficult; you may realize it too late. Once a bad actor claims your subdomain, you might not know in time as it will not show up in a scan. The attacker might even put a cat meme on the page and by then, the damage is already done. Remember the hacker ‘Pro_Mast3r’ who took over Donald Trump’s fundraising website due to a DNS misconfiguration issue? The hacker replaced secure2.donaldjtrump.com with an image of a man wearing a fedora with the message:
“Hacked By Pro_Mast3r ~
Attacker Gov’
Nothing Is Impossible
Peace From Iraq.”
Given the urgency to tackle the risk of expired or forgotten subdomains, bringing in external attack surface monitoring can be beneficial. It identifies subdomains that have been misconfigured or unauthorized, so you can find and fix them before a subdomain takeover happens. External subdomain monitoring can help you do a subdomain takeover risk analysis and map out your external attack surface by looking at all expired subdomains. Chauchefoin says, “Going forward, tools like Detectify will become part of the essential toolkit of any Blue Team, as they provide a considerable value for a fraction of the cost of what it would have been to perform it using non-automated means.”
Chauchefoin explains, “It is hard to keep up with the constant feed of new public vulnerabilities and update vital services in a timely manner. Assuring service continuity is a very costly process, and not all vulnerabilities have the same level of criticality.” As a result, tools like Detectify can help your team prioritize this task by notifying them of the presence of actual exploitable vulnerabilities on the perimeter. In fact, Detectify has over 600+ unique techniques to discover subdomain takeovers. Identifying subdomain takeovers is tricky business as they rely on signature-based tests which are prone to false positives due to outdated signatures.
It is impossible for a single person to stay updated with new vulnerabilities and possible misconfigurations. Integrating a team of hackers in this process allows companies to get actionable proof-of-concepts for virtually every new public research, and even zero-days. Detectify leverages a Crowdsource community of over 400 handpicked ethical hackers, who monitor your subdomain inventory and dispatch alerts as soon as an asset is vulnerable to a potential takeover. Its community of bug bounty hunters constantly monitors targets for changes and continuously has an eye on every single subdomain that they can find.
See what Detectify will find in your online attack surface. Start a 2-week free trial or talk to our experts.
If you are a Detectify customer already, don’t miss the What’s New page for the latest product updates, improvements, and new security tests.
Go hack yourself!
The post How to Prevent a Subdomain Takeover in Your Organization appeared first on Blog Detectify.
In an era of escalating cyber threats, enhancing network security is paramount.
This article explores a comprehensive approach to network protection, encompassing network scanning, vulnerability and patch management, user access controls, network segmentation, and employee training.
Highlighting best practices and their importance, it provides critical insights for organizations aiming to bolster their defenses and safeguard their data effectively.
Dive in to understand the intricacies of implementing robust security measures in today’s digital landscape.
Continually, organizations should employ a variety of network scanning techniques to identify potential vulnerabilities and strengthen their overall security posture. Utilizing robust network scanning tools, IT teams can probe their networks for open ports, weak configurations, and other potential weak points. These tools automate the often tedious task of scanning, enabling faster and more accurate detection.
However, identifying vulnerabilities is just the first step. Equally important is vulnerability prioritization, which involves analysing scan results to identify the most critical issues that need immediate attention. This process helps ensure that resources are allocated effectively, addressing high-risk vulnerabilities first.
This combined approach of network scanning and vulnerability prioritization is a fundamental component of a robust cybersecurity strategy.
Here are some of the most popular network scanning tools for :
A comprehensive vulnerability management process is an essential aspect of network security, encompassing the identification, analysis, prioritization, and remediation of potential network vulnerabilities.
Utilizing advanced vulnerability scanning tools, organizations can automate the identification of security loopholes in their network infrastructure. The process doesn’t end at identification; the data gleaned from these scans require careful analysis.
Vulnerability prioritization becomes a critical step here, enabling teams to focus their efforts on the most critical threats first, ensuring optimal use of resources. Once prioritized, vulnerabilities must be remediated promptly, necessitating a robust patch management program.
The continuous cycle of identification, analysis, prioritization, and remediation forms the backbone of an effective vulnerability management strategy, providing a proactive approach towards enhancing network security.
Building on the concept of vulnerability management, an equally significant aspect of network security is the implementation of a robust patch management policy. This involves identifying, acquiring, installing, and verifying patches for systems and applications.
With these steps, organizations can fortify their defenses, keeping their network secure and resilient to potential attacks.
Implementing robust user access control measures is a crucial step in bolstering network security and minimizing potential threats. The bedrock of these controls is enforcing password complexity requirements, ensuring that all users have unique, hard-to-crack passwords.
This involves mandating a mix of uppercase and lowercase letters, numbers, and special characters. While ensuring the set conditions are not so stringent that users start making sequential passwords which are even easier to brute-force.
Coupled with this, periodic password changes can further deter unauthorized access. Yet, password measures alone may not suffice. Hence, implementing multi-factor authentication (MFA) is advised. MFA enhances security by requiring users to provide two or more verification factors to gain access.
This could be a combination of something they know (password), something they have (security token), or something they are (biometric verification).
These stringent measures, when applied correctly, greatly enhance network security. User awareness about limiting their cyber foot print is critical aswell.
In the organization’s pursuit for enhanced security, network segmentation emerges as a vital component. It essentially divides a network into several smaller parts, each acting as a separate entity. This approach yields significant benefits, especially in terms of bolstering the overall security posture.
Implementation of network segmentation, however, necessitates careful planning, along with regular monitoring and updates, to ensure its effectiveness in providing a robust defence against evolving cyber threats.
With the implementation of network segmentation, the utilization of firewalls and access control lists becomes an integral part of securing an organization’s network infrastructure.
Firewalls, when correctly configured, serve as a robust line of defense against unauthorized external access. They scrutinize inbound and outbound traffic based on predefined rules, blocking those which don’t comply.
Access control lists, on the other hand, enforce access control policies, defining who or what is allowed or denied access to a network resource. Both these tools, when used in conjunction, provide a formidable barrier against cyber threats.
However, their effectiveness is largely contingent on the accuracy of their configuration and the appropriateness of the applied access control policies. Regular reviews and updates are essential to maintain a robust defense.
Here are some of the most popular enterprise-scale firewalls:
Beyond the technical measures such as firewalls and access control lists, a crucial component in enhancing network security lies in the establishment of robust employee awareness programs. These programs aim to equip employees with the knowledge and skills necessary to detect, prevent, and respond to potential security threats. They play a pivotal role in phishing prevention and incident reporting, as employees are often the first line of defense against such attacks.
Regular training sessions on phishing prevention and safe online practices.
Hands-on workshops for recognizing and reporting suspicious activities.
Simulation exercises to test employees’ understanding and response to potential threats.
A considerable part of an organization’s defense strategy should be dedicated to the implementation of effective cybersecurity training practices.
The cybersecurity training benefits are manifold and directly contribute to enhancing an organization’s overall security posture.
Training modules should be designed to address the most pertinent threats, including but not limited to, phishing, ransomware, and social engineering attacks.
To make the training more effective and practical, organizations can conduct phishing simulation exercises. These exercises allow employees to experience first-hand how these attacks occur, which in turn enhances their ability to identify and respond to real-life situations.
Additionally, regular updates to the training curriculum are necessary to keep pace with evolving cyber threats.
Plenty of online platforms, like Lumify Learn and Skillshare, provide online cybersecurity training, so it shouldn’t be hard to find one that addresses your company’s needs. Ultimately, a well-trained workforce is a fundamental layer of any robust cybersecurity strategy.
In conclusion, robust network security necessitates a multifaceted approach incorporating:
These practices, when meticulously implemented, offer a formidable defense against cyber threats, thereby securing an organization’s data and systems.
Thus, enhancing network security is a paramount concern, requiring ongoing commitment and strategic planning to ensure effective protection.
The post Enhancing Network Security: Best Practices for Effective Protection first appeared on Internet Security Blog - Hackology.
Yet Another Testing & Auditing Solution
The goal of YATAS is to help you create a secure AWS environment without too much hassle. It won't check for all best practices but only for the ones that are important for you based on my experience. Please feel free to tell me if you find something that is not covered.
YATAS is a simple and easy to use tool to audit your infrastructure for misconfiguration or potential security issues.
| No details | Details |
|---|---|
 |  |
brew tap padok-team/tap
brew install yatasyatas --initModify .yatas.yml to your needs.
yatas --installInstalls the plugins you need.
yatas -hFlags:
--details: Show details of the issues found.--compare: Compare the results of the previous run with the current run and show the differences.--ci: Exit code 1 if there are issues found, 0 otherwise.--resume: Only shows the number of tests passing and failing.--time: Shows the time each test took to run in order to help you find bottlenecks.--init: Creates a .yatas.yml file in the current directory.--install: Installs the plugins you need.--only-failure: Only show the tests that failed.| Plugins | Description | Checks |
|---|---|---|
| AWS Audit | AWS checks | Good practices and security checks |
| Markdown Reports | Reporting | Generates a markdown report |
You can ignore results of checks by adding the following to your .yatas.yml file:
ignore:
- id: "AWS_VPC_004"
regex: true
values:
- "VPC Flow Logs are not enabled on vpc-.*"
- id: "AWS_VPC_003"
regex: false
values:
- "VPC has only one gateway on vpc-08ffec87e034a8953"You can exclude a test by adding the following to your .yatas.yml file:
plugins:
- name: "aws"
enabled: true
description: "Check for AWS good practices"
exclude:
- AWS_S3_001To only run a specific test, add the following to your .yatas.yml file:
plugins:
- name: "aws"
enabled: true
description: "Check for AWS good practices"
include:
- "AWS_VPC_003"
- "AWS_VPC_004"You can get the error logs by adding the following to your env variables:
export YATAS_LOG_LEVEL=debugThe available log levels are: debug, info, warn, error, fatal, panic and off by default
You'd like to add a new plugin ? Then simply visit yatas-plugin and follow the instructions.
At Detectify, the backend team is using Go to power microservices. We noticed one of our microservices had a behavior very similar to that of a memory leak.
In this post we will go step-by-step through our investigation of this problem, the thought process behind our decisions and the details needed to understand and fix the problem.
The post How we tracked down (what seemed like) a memory leak in one of our Go microservices appeared first on Detectify Blog.
The post 5 Things Your IT Department Needs to Be Doing appeared first on Detectify Blog.
The post How to identify a phishing email appeared first on Detectify Blog.
