When designing cloud or on-premise application services the topic can be very complex and dependency driven.

In the following article, we will cover a couple of common network design architecture topics to ensure we meet a minimum security baseline while minimizing maintenance. You can apply most of these concepts across datacenter and cloud environments. From a CISO standpoint, we need to consider confidentiality, integrity, and availability as our three pillars of security when considering risk.

Building a security baseline requires additional time and effort initially but should save effort in the long term. Previously in my past organization, all infrastructure or new builds had penetration testing, DR testing and backup audits to ensure compliance prior to production. This was perfect for the red team since they had no limitations on the attack vector and risks plus we could test our SIEM and security monitor prior to production.

For the purposes of this article, we will define a couple of application examples.

Application Services

• Company Website: WordPress Application that has the following items
  • Apache2 Frontend PHP server
  • Mysql Backend Database Server
• Enterprise Application: This contains company and customer-sensitive private data
  • Dot NET Application
  • Tomcat Server
  • PostgreSQL DB
  • Elasticsearch DB

Network Diagram

Network Segmentation

Often organizations use flat network topology which creates two problems, lack of security and large broadcast range which may result in poor network performance. You can see above we have divided the network into zones used to group common services based on data criticality or risk. When building out complex networks I have used a common approach for example all servers in the application zone can access MYSQL port 3306 in the DB zone. These controls were implemented based on the zone to drive lower maintenance overhead.

Zero Trust Dataflow

• Internal ACL rules are maintained for each subnet based on the destination port or network zone
  • Database Zone 10.16.1.128/27
    • Accept Inbound from 10.16.1.0/26
    • Destination Port 5432 (Postgresql)
    • Destination Port 9200, 9300 (Elasticsearch)
• Outbound Internet can be controlled based on each zones requirements
  • Frontend Zones speak with DMZ WAF over HTTPS/HTTP
  • Company Website and Enterprise Application zone rely on Common Zone for Authentication, NTP and DNS Services
  • Outbound Internet can be blocked with Temporary ACL in place for Updates and/or Maintenance Tasks

Security Controls

• Monitoring Network traffic crossing zones
• Web Application Firewall
• IPS Intrusion Prevention System
• AntiVirus Agents

The above diagram can be scaled to include many zones given we have divided each /24 network subnet into 5 logical subnets. Typically each /24 network has a dedicated VLAN so you can also minimize broadcast zones across your enterprise while building a scalable secure network topology. Internal or External access can be granted to the DMZ zone ensuring the trust path for an external user and internal user are the same. Obviously, internal users would also have a dedicated user network and required access to the common zone.

Hopefully, you found this helpful and will continue to build upon these basic security principles in later blog articles.