Information security starts with good practices at the foundations

Introduction

Most organizations invest in advanced cybersecurity solutions: modern firewalls, intrusion detection systems (IDS), behavioral analytics (UEBA), incident response automation (SOAR). But they make a fundamental mistake: they build these layers on weak foundations.

It's like building a 20-story building on sand. No matter how sophisticated the architectural design, it inevitably collapses.

Real security doesn't start with cutting-edge technology. It starts with fundamental design decisions in telecommunications and network infrastructure -decisions many organizations never formally document.

In this article, we explore how security-driven network design, implementing proven principles like least privilege and network segregation, is the foundation any robust cybersecurity program must be built on.

Why is telecom design a security problem?

The gap between intention and reality

Ask any IT lead: "Does your network follow the principle of least privilege?"

The answer is almost always the same: "Yes, we have policies."

But when the technical reality gets audited, they find:

• Users connected to networks they don't need for their role
• Server access without specific port restrictions
• Internet access with no segmentation: every device on the same VLAN
• Configuration changes implemented without documentation
• Administrators with unlimited access from anywhere
• Critical servers reachable from user networks

The cause: it's not a lack of intent. It's that the telecom design was built for connectivity, not security. And as the organization grows, that design becomes technical debt.

The real impact

According to Verizon's latest breach report:

• 60% start with initial access exploiting network misconfigurations
• 45% involve lateral movement within poorly segmented networks
• 30% are caused by undocumented or unauthorized changes

In other words: most security incidents depend on telecom deficiencies.

The 6 foundations of a secure network

A secure telecom architecture rests on six fundamental principles. They're not new. They're proven. But they require discipline to implement.

1. Principle of least privilege in telecommunications

Definition: every device, user and service should have access only to the resources it needs for its specific function. Nothing more.

Practical implementation:

INCORRECT example:
- Sales user: Access to the entire corporate network
- Web server: Connected to the database network
- Printer: Unrestricted internet access
- Employee laptop: Access to administrative servers

CORRECT example:
- Sales user: Sales VLAN + CRM server + floor printer
- Web server: DMZ VLAN (isolated), connects ONLY to a specific API
- Printer: Printer VLAN with internet access blocked
- Employee laptop: User VLAN, no access to administrative servers

How to implement it:

1. Needs mapping: document which connections each role/device actually needs
2. Granular firewall policies: per connection (source, destination, port, protocol, schedule)
3. Periodic review: audit quarterly that permissions are still needed
4. Technical validation: don't trust "it should work"; test every change

2. Restricting internet access: the perimeter matters

The problem: allowing unrestricted internet access from the corporate network is accepting that any malware, data exfiltration, or phishing is possible.

The reality in 90% of organizations:

• All traffic exits through a proxy, but almost nothing is blocked
• Access to social media, streaming sites, P2P downloads
• Users can download executable files without restriction
• No visibility into what data leaves the network

Secure internet egress design:

Internal Corporate Network
  ↓
Critical Servers (Isolated)
  - Databases (No internet access)
  - Administrative systems (Restricted)
  ↓
NGFW/Proxy (Fortinet)
  - DLP (Data Loss Prevention)
  - URL filtering
  - Antivirus/AV
  - SSL inspection
  ↓
Internet

Concrete policies:

3. Port control: closed by default

Simple principle: all ports closed by default. Only open what's explicitly used.

Real example: a database server shouldn't have port 3389 (RDP) open to the world. It should only be reachable from specific application servers, during maintenance windows, from authorized IPs.

Common port audit (typical organization example):

Port 22 (SSH)         - Open to the internet          → Incorrect
Port 3306 (MySQL)     - Reachable from any PC          → Incorrect
Port 5432 (PostgreSQL)- No source restriction           → Incorrect
Port 3389 (RDP)       - Exposed to the internet          → Incorrect
Port 445 (SMB)        - No network authentication        → Incorrect
Port 53 (DNS)         - Open to external queries         → Incorrect

Correct design:

Database Server
├─ Port 5432: Open ONLY to:
│   ├─ 10.1.1.0/24 (Applications VLAN)
│   └─ Schedule: Monday-Friday 07:00-19:00
├─ Port 3389 (RDP): CLOSED (access only via jump host)
└─ All other ports: CLOSED

4. Network separation: logical segregation

Concept: split the infrastructure into isolated security zones. Lateral movement becomes exponentially harder.

Reference architecture (3 layers):

┌──────────────────────────────────────────┐
│ DMZ (Demilitarized Zone)                  │
│  └─ Web servers, public APIs              │
│  └─ Isolated: no access to internal data  │
└────────────────┬───────────────────────────┘
                  │ (Internal firewall)
┌────────────────▼──────────────────────────┐
│ Corporate Network (Internal Zone)          │
│  ├─ User VLAN (Desktops, laptops)          │
│  ├─ Application Server VLAN                │
│  ├─ IP Telephony VLAN                      │
│  └─ IoT VLAN (Printers, CCTV, etc.)        │
└────────────────┬──────────────────────────┘
                  │ (Internal firewall)
┌────────────────▼──────────────────────────┐
│ Critical Data Network (Restricted Zone)    │
│  └─ Databases                              │
│  └─ Administrative systems (AD)            │
│  └─ Backup/Disaster recovery               │
│  └─ Sensitive file servers                 │
└─────────────────────────────────────────────┘

Advantages:

• Incident containment: if the user VLAN is compromised, critical servers stay protected
• Regulatory compliance: many regulations require segregation (ISO 27001, GDPR)
• Performance: less congestion, controlled broadcast domains
• Operational simplicity: clearer, more auditable firewall policies

5. Limiting server access: de facto, not de iure

Common problem: "our database servers are protected by a firewall" vs. the reality: 500 IPs can connect because ad-hoc rules were added over time.

Database Server - Access allowed ONLY from:
1. Web Application (IP 10.1.2.15): Port 5432
2. Mobile App API (IP 10.1.2.16): Port 5432
3. Backup Server (IP 10.4.1.50): Port 5432 (Backup) + 22 (SSH)
4. Administrator: Only via Jump Host from 10.3.1.1
Everything else: DENIED

Implementation:

1. Access inventory: document every service that needs to connect
2. Host firewall: in addition to the perimeter firewall
3. Periodic validation: audit every 90 days that rules are still valid
4. Alerts: notification if a disallowed connection is attempted
5. Bastion host / jump box: administrative access only through a control point

6. Administrative access control: the critical point

Reality: administrative access is the holy grail for any attacker.

Common mistakes:

• Administrators with shared credentials
• Passwords saved in .txt files
• Remote access (RDP) without MFA from the internet
• Changes made without an audit trail
• One administrator with access to EVERYTHING
• No credential rotation

Secure model (Zero Trust for admins):

Administrator wants to access a Production Server

1. STRONG AUTHENTICATION
   ├─ Username + password
   ├─ MFA (Authenticator, FIDO2, etc.)
   └─ Device posture validation

2. EXPLICIT AUTHORIZATION
   ├─ Access to the specific server only
   ├─ Access to the specific port only
   ├─ Validation of the changes to be made
   └─ Approval from a second administrator

3. THROUGH A BASTION / JUMP HOST
   └─ No direct access. The intermediary logs and audits.

4. FULL LOGGING
   ├─ Who, what, when, from where
   ├─ Session recording
   └─ Real-time alerts

Concrete implementation:

• PAM (Privileged Access Management): Fortinet, CyberArk, etc.
• MFA for all administrative access
• Hardened jump host: the only way to reach production
• Change auditing: GitOps, Ansible with logging, Change Advisory Board (CAB)
• Password rotation: every 90 days at most
• Planned and documented change management

The most underestimated risk: poorly implemented configuration changes

A badly implemented configuration change exposes more than any exploit.

Why is this critical?

• Firewall rules written "on the fly"
• Servers reconfigured without tracking
• Updates with no rollback plan
• Nobody knows why that rule exists

Secure change process:

1. CHANGE REQUEST
   - Description: what, why, impact
   - Owner: who's doing it
   - Date/window: when
   - Rollback plan: how to revert
   - Documentation: before/after

2. REVIEW AND APPROVAL (CAB)
   - Technical team validates
   - Stakeholders review impact
   - Formal approval

3. CONTROLLED IMPLEMENTATION
   - In a test environment first
   - Scheduled maintenance window
   - Active monitoring during the change
   - Rollback on standby

4. VALIDATION AND DOCUMENTATION
   - Verify the change works
   - Update documentation
   - Logged audit trail
   - Lessons learned

Tools and practices:

• Infrastructure as Code (IaC): Terraform, Ansible
• Version control: Git (every change traceable)
• Change Advisory Board (CAB): a cross-functional team
• Change window: only during scheduled hours
• Rollback plan: there's always a plan B
• Post-implementation review (PIR): lessons learned

Implementation: a realistic roadmap

You don't implement all of this in a week. Here's a 90-day roadmap:

Phase 1 (Weeks 1-2): Assessment and documentation

• Full audit of current access (who can connect to what)
• Mapping business flows (what actually needs to connect)
• Inventory of servers and open ports
• Review of existing change policies

Phase 2 (Weeks 3-6): Detailed planning

• Secure network architecture design (DMZ, VLANs, zones)
• Firewall policies by user group
• Administrator procedure (MFA, PAM, Bastion)
• Formal change management process

Phase 3 (Weeks 7-12): Gradual implementation

• Implement network segmentation (VLAN by VLAN)
• Configure NGFW firewall with policies
• Deploy jump host / bastion
• Implement MFA
• Train the IT team

Phase 4 (Ongoing): Monitoring and improvement

• Quarterly access audit
• Policy optimization based on logs
• Review of implemented changes
• Documentation updates

Conclusion: the foundations hold everything up

A modern cybersecurity program (SIEM, SOAR, threat intelligence, automation) is powerful. But only when it rests on solid foundations.

A well-designed network -with least privilege, clear segregation, controlled administrative access, and documented changes- exponentially reduces the attack surface.

It's unglamorous. It doesn't show up in executive presentations or press reports. But it's the difference between an organization that contains incidents quickly and one that suffers massive breaches.