DNS
Finds the published service.
APPLICATION & WEB SECURITY
Your application needs to be available. That does not mean it must be exposed without controls.
Portals, corporate systems, APIs, and web services connect customers, employees, partners, and applications directly to organizations' digital processes.
Every published service also expands the surface that needs to be understood, controlled and monitored.
Add Solution designs and implements security architectures for web applications and services, combining WAF, HTTP/HTTPS protection, TLS, access control, policies, visibility, and integration with security infrastructure to reduce exposure without compromising the legitimate user experience.
INTERNETTLSIDENTITY
WEB PROTECTION / POLICY
APPLICATIONAPIBACKEND
ENGENHARIA APLICADA
Proteger aplicações exige compreender exposição, fluxo e comportamento legítimo.
A Add Solution conecta WAF, proteção de APIs, TLS, políticas, telemetria e processos de correção sem confundir mitigação com eliminação da causa.
Arquitetura, execução e operação tratadas como partes da mesma responsabilidade.
THE APPLICATION IS PART OF THE PERIMETER
When an application is accessible over the Internet, its interface becomes part of the exposed surface.
DNS, addressing, firewall, NAT, load balancing, reverse proxy, TLS, WAF, application, API, backend, and identity form a chain.
Network
Delivers controlled connectivity.
Firewall
Controls communications between zones.
TLS
Protects data in transit.
WAF
Adds HTTP/HTTPS context.
reverse proxy
Mediates publication.
Application
Deliver the business function.
Backend
Processes services and data.
Protecting only the entry point does not mean understanding what passes through that point.Network Security & Firewall
FIREWALL ≠ WAF
Firewall and WAF protect different layers of the architecture.
A firewall controls network communications based on addresses, ports, protocols, and other context. A WAF analyzes web requests and responses to apply HTTP/HTTPS and application policies.
NETWORK SECURITY → HTTP/HTTPS → APPLICATION SECURITY
Allowing HTTPS on the firewall is necessary to publish an application. That does not mean all content transported over HTTPS should be considered legitimate.
A WAF adds application context to the protection of a published service.
HTTP/HTTPS inspection, request and protocol validation, signatures, behavioral controls, reputation, rate controls, positive or negative policies, protection against attack classes, and logging may be available depending on the platform.
A WAF adds a layer of protection. It cannot fix an insecure application on its own.
Frameworks help us understand risk classes.
Access control, injection, insecure configurations, authentication, components, integrity, logging, SSRF, and other risks must be analyzed according to the application, architecture, and context. A WAF does not eliminate the OWASP Top 10.
We can block what we know to be malicious—and define what should be allowed.
Negative security identifies unwanted patterns; positive security defines expected characteristics for specific interactions according to capability and context.
The better we understand legitimate behavior, the better we can distinguish what requires attention.
HTTPS protects data in transit. It does not determine whether a request is legitimate.
Certificates, termination, offloading, the chain of trust, protocols, ciphers, renewal and validity are all part of the architecture.
Encryption protects communication in transit. It does not automatically make the content being transported secure.
Validity and the chain of trust are also operational requirements.
Inventory, validity, renewal, chain, domains, SAN, wildcard where applicable, automation, and monitoring when supported reduce failures caused by expired or incorrect certificates.
The application does not necessarily need to be published directly to the Internet.
Intermediation, TLS termination, routing, headers, policies, WAF integration, and load balancing can reduce direct backend exposure without guaranteeing absolute protection.
Not every web application has a human interface.
Endpoints, methods, authentication, authorization, tokens, rate limits, schema, validation, logging, inventory and exposure need to be considered according to the solution.
An API may not have a user interface. Even so, it can directly expose a critical business function.
The application needs to know not only where the connection came from, but also who is requesting access.
Authentication, MFA, SSO, identity, authorization, context, and sessions can be integrated into the architecture.
Zero Trust & Secure Access PAM & Identity SecurityNot all automated traffic is malicious—and not all automated traffic is wanted.
Crawlers, scrapers, legitimate automation, abuse, credential stuffing, rate controls, and bot management where supported require context.
The challenge is not simply to block automation. It is to distinguish legitimate behavior from abuse.
Excessive use must be addressed within the application context.
Requests, origin, endpoint, session, API, and identity can guide controls according to the platform. Rate limiting does not constitute complete DDoS protection.
Availability can be attacked at different layers.
Volumetric, protocol/network, and application attacks may require controls distributed across the carrier, edge, firewall, specialized services, WAF, and application.
No single point in the architecture can absorb every type and volume of attack.
When remediation cannot happen immediately, compensating controls can reduce exposure.
Where supported, virtual patching can temporarily mitigate certain vulnerabilities or known patterns.
Mitigating exposure buys time. Fixing the root cause remains the goal.
Protection that blocks legitimate users also creates a business problem.
Baseline, learning where available, logs, justified exceptions, policies, false positives and negatives, validation, and continuous tuning balance protection and operation.
Application security must protect the service without preventing it from fulfilling its purpose.
The protection layer must also be designed so that it does not become a single point of failure.
Redundancy, HA, health checks, load balancing, dependencies, certificates, DNS, upstream, and backend guide the architecture without promising zero downtime.
Data center CloudBlocking a request is important. Being able to explain why it was blocked is equally important.
Request, source, host, URI, action, policy, event, timestamp and context can provide evidence, depending on the platform.
Protection generates events. Analysis turns events into evidence.SIEM & Security Analytics
Web events gain context when correlated with other controls.
WAF → EVENTS → SIEM → CORRELATION → INVESTIGATION
Firewalls, endpoints, identity, servers, and cloud can participate when integrations are available.
The application can be anywhere. The policy must follow its architecture.
On-premises environments, data centers, cloud, multicloud where applicable, hybrid applications, and distributed services require a coherent design.
CloudThe best way to protect certain services may begin by not publishing them directly.
Need, origin, users, private applications, administration, VPN/ZTNA, allowlists, reverse proxy, and segmentation must be assessed.
Before protecting an exposure, it is worth asking whether it really needs to exist.
PUBLISHED APPLICATION ASSESSMENT
Do you know exactly which of your organization's services are exposed to the Internet?
We assess the entire chain to discover, classify, analyze, protect, validate and monitor exposures.
01DNS
02IPs
03Ports
04TLS
05Certificates
06Applications
07APIs
08Firewalls
09NAT
10Reverse proxies
11WAF
12Headers
13Policies
14Logs
15Backends
16Dependencies
17Access control
IMPLEMENTATION
Placing a WAF in front of the application is the beginning of the deployment, not the end.
First understand the application. Then progressively increase policy enforcement, avoiding restrictive policies without a baseline of legitimate use.
01DiscoverInventory applications and exposures.
02UnderstandUnderstand legitimate behavior.
03BaselineObserve traffic and dependencies.
04Set policiesRelate risk, context and operation.
05PilotValidate within a controlled scope.
06ProtectProgressively increase enforcement.
07ValidateTest legitimate access and restrictions.
08ObserveMonitor events and availability.
09AdjustContinuously fine-tune policies.
TROUBLESHOOTING
When an application stops responding, the problem may be well before the code.
DNS → NETWORK → FIREWALL → TLS → WAF → REVERSE PROXY → APPLICATION → BACKEND
Diagnosing published applications requires an understanding of the entire chain between the user and the service.
ADD SOLUTION METHOD
Engineering to protect the path to the application.
Over 15 years of experience connecting networking, firewalls, WAF, DNS, TLS, servers, cloud, identity, observability, and operations.
- 01
Discover
Services and published surfaces.
- 02
Map
Chain between user and application.
- 03
Classify
Criticality, audience, and dependencies.
- 04
Design
Controls and availability.
- 05
Protect
Apply appropriate policies.
- 06
Validate
Confirm protection and operation.
- 07
Observe
Produce evidence and context.
- 08
Adjust
Balance security and legitimate use.
- 09
Evolve
Monitor application changes.
The tool applies policies. Engineering determines where, how and why those policies should exist.
TECHNOLOGIES & PRODUCTS
Architecture, protection, integration, and operation.
Vendors and platforms belong on the technology pages. Here, the focus is on protecting the business function without compromising its availability.
Cybersecurity Technologies & ProductsPERGUNTAS FREQUENTES
Decisões importantes sobre Segurança de Aplicações & Web
Respostas objetivas para dúvidas técnicas e operacionais que costumam surgir antes de um projeto.
01WAF substitui firewall?
Não. Firewall e WAF protegem camadas distintas e podem atuar de forma complementar.
02HTTPS significa que a aplicação é segura?
Não. TLS protege a comunicação em trânsito; não determina se o conteúdo ou a requisição são legítimos.
03WAF corrige vulnerabilidades da aplicação?
Não. Pode adicionar proteção e, em alguns casos, mitigação temporária, mas a correção da causa continua necessária.
04Virtual patching substitui atualização definitiva?
Não. É um controle compensatório temporário quando suportado e adequadamente configurado.
05Rate limiting elimina DDoS?
Não. Disponibilidade pode exigir controles distribuídos entre operadora, edge, firewall, serviços especializados, WAF e aplicação.
FALE COM UM ESPECIALISTA
Vamos conversar sobre Segurança de Aplicações & Web.
Share the context of your environment, the perceived impacts and the results your organization seeks. Add Solution will direct the conversation to the most appropriate experts.
CONTEXTO DA CONVERSASegurança de Aplicações & WebOrigem e interesse são registrados automaticamente no atendimento.