An Organically Grown Service Lacking in Structure

To modern readers, the idea of selling a managed firewall service without structured tooling or auditability might seem maverick. But in the late 1990s and early 2000s, it was the norm, especially in a context like ours. We weren’t adapting to an established security ecosystem because it didn’t really exist yet; we were among many companies helping to create and shape it. We were an internet service provider, one of the early adopters and a prominent ISP, so there was a reasonable expectation from the market that we would also provide security services since we were providing the service which created the need for internet security.

At the time, most enterprise networks followed a hub-and-spoke topology to a higher or lesser degree. Internet access typically terminated at a topologically “central” point, with remote offices connecting via leased-line or frame relay WAN links to that central office and having traffic routed over “the internet link”. Meaning that the network was considered internal and the firewall would “stand guard” at the perimeter or singular entry point for external traffic into the network. Security practices, like the networks themselves, were fragmented. Cisco routers, which we supplied, supported basic Access Control Lists (ACLs) which meant simple packet filtering, but this was no substitute for a firewall.

True firewalling, stateful inspection, was still the domain of expensive dedicated appliances like the Cisco PIX, Lucent Brick, or the leaders in the field, Check Point FireWall-1 which ran on hardened Unix systems. These were complex and cost-prohibitive for all but the largest enterprises. For mid-sized South African businesses, firewalls were often considered optional because the risks weren’t as well developed yet or firewalls and management services were unaffordable. Even where the need existed, the tools and budget often didn’t and like insurance a firewall was a grudge purchase.

It's true for some businesses that they were casual about security, maybe too casual, but context mattered. This was still early. Check Point’s first firewall product launched in 1994, and even though it was nearly a decade later, adoption had remained slow for various reasons. Increasing security risks were just beginning to shift Firewalls from niche to necessity.

The threat environment was very different to that we face today. In 2001, most internet users connected via temporary dial-up links. It’s estimated that over 80% of users at the time weren’t online persistently. Attacks were infrequent, the pool of targets was small, and few endpoints were always reachable. Today, with more than 5 billion users and over 30 billion always-connected devices, the threat surface is continuous. But in that earlier era, the risks were lesser and sporadic, and for smaller businesses, already paying very high costs for internet access, the additional cost of a managed security service was a heavy weight to carry.

As security concerns gradually grew with the increased dependence on online systems, many clients began asking if we could “look after the firewall too.” We already managed their routers, and some of our engineers had learnt firewall configuration and security skills, out of necessity to protect our own infrastructure, and out of personal interest. So in the late nineties we’d said yes. That became the basis for our Managed Firewall Service: not entirely a formally launched product, but an extension of router management.

It was a time of great change for business, and the original structure hadn’t come from a product development function because no such thing had existed yet, it had come through legal risk management. A member of the legal team, Eben, had stepped up and developed the service parameters to reduce liability and mostly in the form of contractual expectations which in turn were vetted by Nic, the network manager and Greg, the technical director. It was a functional short-term measure, but it lacked the architecture, strategy or clarity to scale and the product vision to compete or even to meet the needs of the customer base. What Eben had produced was a service which had the primary attributes that it was possible and had an acceptable risk profile.

Two years later, despite substantial effort from Pam one of the first members of the new product management function, that ad hoc model remained largely unchanged. We charged per device, at a level derived from our router support fee, and did what we could to meet customer expectations. Things were changing fast, and security wasn’t just a technical function anymore. It was becoming core to business continuity and brand trust. The service we were delivering wasn’t meeting the market, the moment.

Efforts to adapt to the changes began early in 2002. Some customers expected service guarantees, faster support, and detailed reporting, Intrusion detection and prevention and response to events and alerts. Internally, we knew that we couldn’t keep scaling an informal service. Some were asking about Service Level Agreements, turnaround time guarantees, some even guarantees of protection. We needed proper tooling, stronger governance, and a platform that could handle security at scale.

For the bulk of our customers, the mid-sized and fast-growing firms, there were no other realistic options. Dedicated IT security companies existed, but they catered to high-end clients and came with high-end pricing. Even our earliest firewall service, imperfect as it was, gave customers access to security expertise they couldn’t otherwise afford.

For our larger corporate and multinational clients, the gaps were clear. We needed to do better.

There had even been an earlier opportunity. In 1999, after acquiring SDN (Satellite Data Networks), we gained access to a more structured Linux-based firewall capability. Software tools were procured to support it, but internal resistance and skill attrition meant the systems were never implemented. A foundation had been laid but never built upon.

By the time this project began in earnest as late as 2004, the groundwork was old, and the problems were increasingly visible. The need for change was clear. The appetite for it, less so.

The Turning Point – Recognizing the Gap

By this time, the firewall service had reached a limit. Our clients were growing in size and complexity. Security threats were evolving. Expectations around uptime, accountability, and service structure were rising fast. Internally, we all knew that the way we had started, informally, cheaply, and organically, wouldn’t scale.

Efforts to professionalise were already underway. In 2004, Pam, our now Product Manager for Security, led an RFP process to identify a third-party provider who could manage and monitor Cisco firewalls and the then-emerging IDS/IPS devices. The RFP was comprehensive and forward-looking. It outlined what a mature MSSP should offer: 24x7 monitoring, structured SLAs, policy change control, incident response, customer reporting portals, the full stack.

Pam’s strategy was solid and met the standards, but the RFP failed, the market was ready, but the business couldn’t back her, couldn’t deliver to her plans. The business lacked the structures needed to absorb the service it envisioned. We didn’t have the platforms, internal boundaries, or data segmentation to deliver that level of managed security, let alone support a partner doing it on our behalf.

Security expertise existed, but it was rooted in protecting our own infrastructure, not in delivering a productised customer service. Interested and dedicated engineers were skilling themselves, but turning internal knowledge into a scalable offering required capabilities we hadn’t built:

• Security configurations for routers lived in the same CVS repositories as general router configs, with no segmentation or audit trail and no distinguished processes.
• For those firewalls we had configured there were no established processes and while there was some segmentation it was less formalized and less separate than it should have been.
• We lacked centralized authentication or user-level accountability, engineers logged in via NCS, but credentials were stored locally.
• Access control was flat. NOC and CSC engineers could view and change customer security settings, often without policy enforcement.
• Security wasn’t a separate function. It was just another responsibility for engineers who also managed routers. So there were no internal structures, no tiered support, no clear boundaries, and no abstraction between customer and internal data.

And that wasn’t the only obstacle. The available tooling from other vendors (Lucent, Checkpoint, Fortinet, Juniper) was built around hardware distribution, not managed services. That meant any platform investment came with a strategic lock-in, and the cost and complexity were carried entirely by us. Cisco, by contrast, had a clearer managed service vision, and we were already aligned with them. The CiscoWorks stack offered a path forward, if we could fund and implement it.

Our workaround at the time, outsourcing Lucent Brick firewalls to a third-party partner, only added complexity. They ran their own infrastructure, their own management platform (LSMS), and set their own pricing. We carried their tooling costs, their engineering margins, and had no control over delivery. Worse still, their service, priced for cheaper hardware, was undercutting our Cisco offering, making it harder to justify a price point for managed security.

Internally, the Cisco pricing model had its own flaws. It was inherited from our “Managed Router Rental” product and assumed minimal intervention after deployment. That didn’t work for firewalls, which required regular updates, reconfiguration, and monitoring. Pam had introduced a tiered pricing model for Cisco PIX firewalls, bundling the device and management into a monthly rental. But the economics were tight. A PIX 515E with import duties and taxes cost over R40,000, at the time just less than an entry level car. On a 12- or even 24-month contract, there was almost no margin left for actual management. Even 36-month deals were a tough sell, especially when customers already owned competing hardware.

The result: the service was structurally limited. It wasn’t priced for what it needed to do. It didn’t support customer-owned firewalls. And the systems required to grow it, SOC, SIEM, platforms, processes, policies, were still aspirational.

Pam’s RFP showed vision, but it also revealed the depth of the problem. This wasn’t just about launching a new product. It was about building the foundations to support one.

And that’s when we pivoted. Rather than pressing forward with a centralized, outsourced model we couldn’t yet support, we focused inward, on building the platform, the systems, and the operational discipline that would eventually make true managed security possible. One layer at a time.

The Tactical Layer – Enforcing Discipline and Control

The first step toward a real managed security service was enforcing operational discipline, without disrupting daily delivery. That meant embedding structure into our tooling and processes while preparing for a future platform that could scale.

At the time, we used a homegrown configuration system called NCS (Network Configuration System), built around CVS (Concurrent Versioning System) and RANCID (Really Awesome New Cisco Config Differ). It pulled router and firewall configs from the field and stored them as versioned text files. Crude by today’s standards, but it worked, because we enforced discipline at the naming layer.

Interfaces kept their technical names (e.g., Ser0, Eth1), but NCS required engineers to assign a structured alias, validated at input, that encoded location, product, and circuit type. Names like AND008-cti1-int-fib-1 weren’t just labels, they were metadata.

That structure let us:

• Map physical infrastructure, interfaces in gateway routers or hosting switches to billing systems.
• Generate revenue reports per product, region, or delivery method.
• Feed data to VUGraph, our RRDTool-based customer dashboarding system.
• Enforce access control through LDAP, so customer staff only saw what they were meant to.

It was a powerful system for managed router services and a strong incentive for customers to let us manage their CPE. But it was never designed for firewall management, and it showed.

There was no role separation between network and security. Firewall configs sat in the same repo as routers. NOC engineers had full access. No change workflows, no segmented audit trails, and no structured security career path. It worked because our engineers were good, but it couldn’t scale, and it couldn’t withstand external scrutiny.

Despite these gaps, we had already been granted Cisco MSSP (Managed Security Services Provider) status, one of only two companies in South Africa at the time. Maintaining that status required us to carry a mix of certified Cisco engineers: many CCNAs, some CCNPs, and ideally, at least one CCIE. Cisco was flexible on the exact mix, but the point was clear, this wasn’t a box-drop operation. Security had to be a capability.

That’s when we brought in CiscoWorks Resource Manager Essentials (RME). It wasn’t perfect, but it was a leap forward. RME gave us:

• Automated backups and config versioning
• Job scheduling and rollback support
• A GUI that supported structured change control
• Auditing, accountability, and policy enforcement

Critically, RME didn’t force a rigid workflow. Engineers could still use the CLI to test, then upload configs via TFTP or paste directly into RME. That balance, engineer flexibility with system-level control, was essential to adoption.

This was more than just a tooling upgrade. It allowed us to track who changed what, when, and why. It let us begin separating firewall management from general router ops. It let us build confidence in the platform, not just the people.

And it laid the foundation for a true security career path. Future hires to manage firewalls would be security engineers, not network engineers doing double duty.

Our plan was to eventually migrate the entire managed CPE estate, thousands of routers, onto the CiscoWorks platform. But initially, the focus was firewalls. That meant the tooling costs had to be justified by firewall revenue alone.

Cisco’s licensing was per-device, but tiered: the more devices added, the cheaper each one became. The business case depended on this. Until we hit scale, pricing and service discipline had to align tightly. Every config mattered. Every margin mattered.

We were also anticipating the rise of mass-market DSL. It was clear that DSL routers would someday form the bulk of our managed fleet. But at the time, we didn’t yet know what that operational overhead would look like. That modelling ran in parallel to the enterprise work, shaping the longer-term strategy.

In the short term, this tactical layer, structured naming, RME, policy enforcement, was our beachhead. We weren’t just building better configs. We were building the conditions for scale.

The Strategic Layer – Partnering and Platformization

While CiscoWorks RME brought operational control, its real value was strategic: it gave us flexibility. With a platform that enforced standards, tracked changes, and segmented roles, we could finally rethink how security services were delivered, through internal teams, partners, or even customers themselves.

This mattered, because we couldn’t build everything in-house overnight. We didn’t yet have a dedicated Security Operations Centre (SOC), 24x7 firewall support, or a full bench of security engineers. But we did have trusted customer relationships, operational oversight, and now, a common platform to plug into.

That’s where we shifted toward a deliberate partnership strategy. We evaluated several vendors and pursued a Build-Operate-Transfer (BOT) model with a security firm that already had a working SIEM, a staffed monitoring centre, and mature processes. They would handle operations initially, while training our staff, letting us launch the service immediately while developing in-house capability for the long term.

The difference from previous outsourcing attempts was stark. This time, we had control. RME allowed us to segment configs, define clear boundaries, and retain full visibility, even if day-to-day execution was temporarily external. We stayed in charge of billing, SLAs, and the customer relationship.

This approach also addressed a long-standing vulnerability: our total dependence on a single partner for Lucent Brick firewall support. That partner ran their own stack, used our customers and pricing, and left us without leverage. With Cisco and RME, we could flip the model, building control into our platform and inviting partners in on our terms.

RME also enabled service modularity. We could now support:

​·       Customer-managed firewalls – we supplied the tooling, the customer ran the ​ ​device.

​·       Reseller-managed firewalls – the reseller took operational control via our ​ ​     platform.

​·      Third-party-managed firewalls – we remained the primary provider, but ​ ​ ​     outsourced some execution.

This wasn’t just scaling, it was ecosystem-building. We were standardizing pricing, tooling, reporting, and policies across all service models.

And this made the biggest shift of all: we weren’t just offering firewall management. We were offering capability. One that could flex around the customer’s needs, enable channel partners, and deliver value whether managed internally or externally.

What began as a bolt-on task was evolving into a platform strategy. Quietly, but powerfully, it was becoming a foundation for the future of our managed services business.

The Business Layer – Fixing the Revenue Model

All the tooling, process design, and strategic partnerships in the world wouldn’t have mattered if we didn’t fix the core issue that had made the original service unsustainable: pricing.

Originally, Cisco firewalls were priced like routers, R350 per month per device. That figure was a direct inheritance from our legacy CPE support model, where a customer-owned router might receive occasional ACL updates or troubleshooting support. It was never designed for the complexity, risk, or operational demand of perimeter security.

Pam, the Product Manager for Security, addressed this by introducing a bundled rental model. The device and its management were combined into a single monthly fee, with pricing adjusted by device class and contract term. Larger firewalls cost more; longer contracts cost less.

On paper, it made sense. Over a 36-month contract, we could recover the cost of the firewall and begin generating margin. But in practice, it didn’t land. The market was evolving quickly, by the time a customer reached the break-even point, the firewall was likely out of date, possibly even insecure. UTM (Unified Threat Management) was on the rise. IDS and IPS were gaining traction. Security lifecycles were shortening, not lengthening.

Worse still, our primary competitor had underpriced their offering too, creating market pressure that forced us to hold pricing below where it needed to be.

That left no margin for:

• 24x7 support or SLA-bound service guarantees
• Patch cycles or software upgrades
• Configuration backups or rollback infrastructure
• Internal segmentation or auditing
• Training, certifications, or staff development
• Platform licenses like RME
• Third-party partnerships or tooling integration

We were subsidizing a product we didn’t fully control, couldn’t scale, and weren’t being paid to improve. Any platform investment, whether in RME, policy enforcement, or partner enablement, came straight out of non-existent margin.

Fixing that meant more than just changing the number on the invoice. It meant reframing the service: not as low-touch tech support, but as a structured, auditable, risk-managed security capability.

We introduced tiered service levels, with pricing linked to real feature differentiation:

• Managed vs. customer-managed models
• Interface/VLAN complexity
• Hosted virtual firewalls on switch blades
• SLA-linked response times and uptime guarantees
• Reporting dashboards and config archives
• Optional 24x7 monitoring and alerting

Thanks to RME and the structured metadata in NCS, we could finally prove value. Naming conventions mapped to billing; reporting tools could show uptime, changes, issues resolved. Customers didn’t just get “support”, they got visibility, accountability, and business continuity assurance.

Internally, we decoupled security from general network support. Firewalls weren’t just “another box.” They were the first real step in defining security as a standalone line of business. And the same model could be extended across our broader CPE estate.

We were increasingly managing high-end customer hardware, Cisco 7609s and 6509s, where the needs were closer to hosted infrastructure than branch office routing. These services demanded policy enforcement, audit trails, and change workflows. The investment in structured tooling paid off across product lines, not just security.

At the same time, IDS/IPS services were becoming viable. Customers were asking for real-time intrusion detection, proactive mitigation, and event correlation. Our firewall pricing model, now aligned to risk, value, and operations, became the blueprint for monetizing those services too.

And critically, we were beginning to plan for customer-controlled services. RME made it possible to template common configurations, validate inputs, and allow secure customer access to infrastructure elements. In the data centre, customers could soon self-configure VLANs, assign ports, and spin up virtual firewalls behind VMware hosts, without compromising the network.

What started as a fix for flawed pricing became a foundation for productization. We weren’t just charging more, we were building a business that could justify, support, and scale what we charged for.

The Result – From Ad Hoc to Strategic Asset

By the time the platform was in place, what had begun as an improvised support task had become a structured, scalable foundation, not just for firewall management, but for a broad portfolio of managed services.

We moved from freeform, router-derived pricing and manually tracked configurations to a model that was auditable, customer-visible, and commercially sound. Firewalls were no longer “just another box.” They were part of a governed service suite, tiered, monitored, reportable, and backed by SLA enforcement.

But more importantly, this wasn’t just a product, it was a repeatable platform model. Using tools like CiscoWorks RME, structured naming conventions, and input-validated config templates, we created a reusable service layer. Security. Managed CPE. Data centre access. Virtual hosting. Each had a core of change control, audit, and automation that could be scaled and adapted.

This strategy made next-generation services possible, especially in the data centre. Customers could soon:

• Request VLANs
• Configure Cisco 6509 switch ports
• Deploy virtual firewalls on blades
• Launch VMs connected to the right segment, behind segmented firewalls, using pre-validated templates

All of it ran through a framework we owned and governed. No ad hoc approvals, no undocumented changes. This agility was unheard of at the time, and unavailable anywhere else.

Cloud platforms like AWS, Google Cloud, and Azure didn’t yet exist. Even companies like Triple 4, who offered VMware-based services, required manual provisioning. Self-service infrastructure was still a vision, not a capability. Verizon, our global parent, would only begin launching its own cloud offering around 2006. We were ahead of that curve, technically, operationally, and strategically.

And because the same platform supported both firewalls and routers, we gained powerful scale benefits: shared reporting, common training, consistent processes. It positioned us to responsibly expand into areas like Intrusion Prevention (IPS), SIEM integration, and hybrid delivery models, because the control and audit framework was already there.

But the most valuable shift? We stopped firefighting and started designing. Product development became proactive, not reactive. Services could be modeled, tested, and priced with confidence. The platform reduced time-to-market, improved governance, and lifted the floor beneath innovation.

We didn’t just fix a service. We built a capability, one that enhanced customer trust, increased resilience, and made the business more scalable, more strategic, and more valuable.

Lessons Learned – Building Capability Before Product

This wasn’t just a technical uplift. It wasn’t a procurement project or even just a restructure. It was a shift in how we understood the relationship between service delivery, product structure, and organizational readiness.

The original firewall service didn’t fail because of bad intent or poor engineering. It failed because the business hadn’t yet built the systems, pricing models, governance, or process boundaries needed to support it. When we tried to scale or bring in partners without that foundation, the cracks showed immediately.

But when we shifted focus to building capability first, platforms, processes, tooling, naming discipline, auditability, everything else began to fall into place. Pricing became defensible. Partnerships became sustainable. Innovation became repeatable. And most importantly, we created space to align what customers experienced, what engineers built, and what the business could scale.

If there’s one enduring lesson, it’s this:

Sustainable services don’t begin with features.

They begin with infrastructure, technical, commercial, and human, designed to support change.

Once you have that, product development really can move at the speed of strategy.