Unstructured output
Large volumes of discovered URLs and assets were not consistently classified or aligned with the organisation's inventory.
Turning raw securityintelligence intoactionable insights.
Tailoring an OEM-provided External Attack Surface Management platform to meet the operational, technical and security requirements of a large banking environment.
An existing tool.
A different environment.
External Attack Surface Management helps an organisation discover and assess the digital assets exposed to the internet, including URLs, domains and IP addresses.
The organisation was using an OEM-provided ASM platform. However, the output and operating model were not fully aligned with the bank's internal environment and requirements.
My responsibility was to identify these gaps, define the required changes and work with the OEM's product and development teams to make the platform fit the organisation's use cases.
PRODUCTExternal Attack Surface Management
PLATFORMOEM-provided ASM tool
MY ROLEProduct requirements & execution
COLLABORATIONInternal teams & OEM leadership
02 / THE PROBLEMMore data didn't mean
01 / DATA QUALITY 02 / RELEVANCE 03 / SCANNING 04 / BANK ENVIRONMENT
More data didn't mean
better visibility.
The platform was discovering large volumes of external assets, but the output required significant interpretation before it could become useful operational intelligence.
Noise and false positives
Static pages, error pages, irrelevant URLs and other outliers made it difficult to identify the assets that actually mattered.
Operational disruptions
Heavy scanning traffic and network restrictions resulted in downtime and cases where scanner traffic could not reach certain URLs.
Environment-specific requirements
The OEM's default configuration needed to be adapted to internal security controls, asset inventory practices and reporting expectations.
Four areas of
product improvement.
Control how assets are scanned.
Customised scanning modules and Nexus templates, defined the appropriate scope and worked towards scheduling scans during non-business hours.
Understand what was discovered.
Improved the classification approach to distinguish relevant URLs, static pages, dynamic pages, error pages and IP-based URLs.
Make the output actionable.
Defined custom rules, filters, SLA tags and reporting tags to make the output more structured and aligned with internal assessment requirements.
Connect discovery with ownership.
Improved the assessment of discovered URLs against internal inventory and considered code repository information to help identify false positives and outliers.
04 / ASSET INTELLIGENCEFrom discovered URLs
From discovered URLs
to meaningful asset intelligence.
A discovered URL should not automatically be treated as a meaningful external exposure. It needs to be assessed, classified and reconciled with what the organisation actually owns.
INPUT
Discovered assets
URLs, domains and IP-based URLs
→
ASSESSMENT
Classification
Static, dynamic, error pages and relevant assets
→
RECONCILIATION
Inventory matching
Compare discoveries against internal inventory
→
OUTPUT
Actionable findings
Relevant assets and items requiring investigation
KEY DISTINCTION
Discovery tells you what is visible on the internet. Classification and reconciliation help establish what is relevant, what is owned and what needs action.
Making scanning work
within a restricted environment.
Scanning generated substantial traffic. In a restricted banking environment, this required coordination with several internal infrastructure and security teams.
I worked on moving scans to non-business hours, obtaining the required approvals and coordinating whitelisting so that scanner traffic could reach the intended assets.
When URLs remained inaccessible, I coordinated troubleshooting sessions to trace live packets and identify where traffic was being blocked.
COORDINATION ACROSS
SOC
DDoS Protection
Web Application Firewall
Load Balancer
Perimeter Firewall
Application-layer Firewall
My role in the process
Coordinated approvals, troubleshooting calls and cross-team follow-ups to identify connectivity issues and enable reliable scanning.
06 / VENDOR EXECUTIONTranslating business needs
Translating business needs
into product changes.
The OEM did not provide access to the underlying source code. Product changes therefore required close coordination with its development organisation.
I identified the gaps, explained the expected behaviour, documented the requirements and coordinated implementation with the OEM's project managers, development teams and CTO.
The focus was not simply to request changes, but to explain what needed to change, why it mattered and how the resulting functionality should serve the bank's use cases.
01Identify the gap
Understand the operational problem
02Define the requirement
Explain expected behaviour and rationale
03Coordinate with OEM
Align project managers and development teams
04Validate the change
Review the resulting functionality
Making the external
asset landscape more actionable.
UNNECESSARY EXTERNAL EXPOSURES IDENTIFIED AND CLOSED
30%
Approximately 300 unnecessary external exposures identified and closed from around 1,000 observed exposures over the reported quarter.
BEFORE ASSESSMENT~1,000
Observed external exposures
UNNECESSARY EXPOSURES CLOSED~300
Items identified as not requiring external exposure
IMPORTANT CONTEXT
This metric represents unnecessary exposures identified and closed, not a measured reduction in all vulnerabilities or all possible attack paths.
08 / KEY LEARNINGSWhat I learned about
What I learned about
building enterprise products.
01An OEM product is only as useful as its fit with the customer's environment, workflows and operating model.
02Large volumes of data do not create value unless they are classified, contextualised and made actionable.
03Product ownership can involve influencing teams outside your organisation, particularly when the underlying technology is vendor-owned.
04Operational reliability is part of product quality, especially in environments with complex infrastructure and security controls.