The first three blogs in this series were all about building a blueprint for a well-designed environment. In this article, we’ll review more practical considerations to influence the overall architecture and design of the ecosystem, which in turn require specific features and methodologies as dictated by the required data flows in our use cases. Many of these concepts may not appear to be focused on security but refer to basic networking and documentation. It’s surprising how many organizations lack a detailed knowledge of their underlying network design and the capabilities of its components, which is a must for the detection and mitigation of threats.

 

Logical design provides data segmentation, the first real step to a secure and resilient design. Sub-interfaces, VLANs, VRFs, virtual, and tunnel interfaces separate traffic and allow various forwarding and security methods to be applied to individual flows. Devices such as firewalls and intrusion prevention appliances may be physically connected to routers or switches; however, logical design features such as firewall contexts and virtual sensors handle the segmented flows.

 

Another key concept is the use of addresses and identifiers as the basis for implementing security policy rules and requirements. Address assignment methods should be controlled and secured. This is simpler for static assignment to resources that don’t change frequently. Dynamic assignment is required for transient users and devices and should be part of authentication and authorization of the end entity. If a DHCP server is used, secure the service using techniques such as DHCP snooping and dynamic ARP inspection. It’s important to track assigned addresses by associating MAC addresses to IPs to prevent spoofing. Using authentication methods such as 802.1X or MAB and tying them to device profiling and security posture assessments introduces the concept of authorized network access based not only on identity but also capabilities.

 

Allocated addresses may need to be translated to allow access to private services from a public network, or to hide the real address of a private resource. Be familiar with unidirectional versus bidirectional access when configuring NAT and PAT methods. If traffic flows are initiated using a translated address, a bidirectional method is required. This can also be combined with application port mapping, which forces connectivity via a non-standard port, hiding the real port. If address translation isn’t an option, but connectivity across a WAN or the internet to remote sites is required, consider tunneling methods such as IPv6-in-IPv4 or IPv4-in-IPv4, which may also be protected with IPsec. Role-based identifiers to add context to a security policy beyond topology dependent constructs such as IP address are also available. Some vendors offer identity-based firewalling, where username to IP address mapping is used to enforce policy.

 

Once end entities access the network, a solid understanding of routing protocols and packet forwarding techniques adds to overall security. Static routes can be used to redirect traffic for security reasons. Policy-based routing can also redirect or discard traffic as well as mark certain flows for priority handling. Be familiar with best practices for dynamic routing protocols as well as any security mechanisms associated with them. For example, authentication of routing updates via MD5 and TTL max hop limits for OSPF and BGP.

 

Understanding the services and functions important to network users and putting together a topology design helps define security policy elements. Enforcement techniques such as access lists, firewall rules, application security attack mitigations, and role-based access controls identify the security feature capabilities needed on network devices.

 

In keeping with best practices, several references are available to assist with secure design, including:

 

  • IETF standards-based BCPs (38), RFCs (1918, 3330, 2827, 3704)
  • Compliance best practices ISO Framework (27001, 27002), COBIT IT security standards
  • Well-known organization documents such as those by SANS and NIST
  • Vendor specific guidelines, recommendations, and limitations
  • Up-to-date vulnerability information from PSIRT, SNORT, and threat intel feeds

 

In the final blog of the series, we will review methods for monitoring and alerting that will be the barometer for measuring the success of our use case deployment.