In the previous blog, we discussed how defining use cases mapped to important security and business- related objectives are the first step in building and maintaining a secure environment. We’ve all heard the phrase, “you can’t defend what you can’t see,” but, you also “can’t defend what you don’t understand.”
Use cases will be built with the components of the ecosystem, so it’s critical to identify them early. Overlooking a key component could prove to be costly later. The blueprint for use case deployment can be drawn up based on three key areas.
- Identify Role Players, Such as Endpoints, Infrastructure, and Users
A network is built using devices such as routers, switches, firewalls, and servers. Their optimal configuration and deployment requires a detailed understanding of the role each device will play in connecting users with applications and services securely and efficiently as mandated by their individual and group roles.
User and endpoint roles can then be mapped to enforcement techniques, authentication and access methods, and
security audit requirements during the deployment phase.
For example:
- Campus-based employees may access the network via wired company-owned devices and authorized for network access by MAB authentication
- Mobile employees require 802.1X authentication via wireless network access
- Guest users with their own wireless devices use Web Authentication and are authorized to access a restricted set of resources
- Branch office connectivity and other remote access users connect via an IPsec VPN with authentication via IKEv2 with RSA signatures or EAP
- Network administrator groups require access to subsets of devices, authenticate per device, and are authorized for specific commands
- Understand Data Flows and Paths
The role players in the ecosystems are connected by data flows. Where do these flows need to go within the network? Where are users coming from? Flows need to be defined. This includes flows between users and services, as well as administrative flows between network infrastructure (think routing protocols, AAA requirements, log consolidation, etc.). As a data flow traverses a known path, identify network transit points such as remote access, perimeter, and even on- or off-premises communications with cloud-based services.
Understanding how data moves through the ecosystem raises questions on how to secure it.
- Should a user be granted the same level of access regardless of their point of access?
- Should data segmentation be implemented, and if so, will physical and/or logical segmentation by used?
- Should all services be located inside my firewall perimeter, on a DMZ, or cloud hosted?
- What types and levels of authentication, integrity, and privacy will be required to secure data flows?
- Identify Software and Hardware, SaaS, and Cloud
Effective configuration and deployment of network elements is dictated by required functions and permitted traffic flows, which in turn drive the choice of hardware and software. Device capabilities shouldn’t define a security policy, although they may enhance it. Choosing products that don’t meet security or business needs is a sure way to limit effectiveness.
Knowing what you need is critical. However, one major influence on security policy is business return on investment. When possible, consider migration strategies using existing infrastructure to support newer features and a more secure design. Relocation of hardware to different areas of the network or simply upgrading a device in terms of adding memory to accommodate new software versions should always be considered. Deprecating on-premises hardware may be considered if a transition to cloud-based services is seen as a more efficient and cost-effective method of meeting security and business objectives.
When selecting new hardware, plan for future growth in terms of device capacity (bandwidth), performance (processor, memory), load balancing/redundancy capabilities, and flexibility (static form-factor versus expansion slots for additional modules). Set realistic and well-researched performance goals to ensure stability and predictability and choose the best way to implement them.
When selecting software, in addition to providing the required functionality, the following points should be considered.
- Evaluate standards-based versus vendor proprietary features.
- If certified products are required, is the vendor involved with certification efforts and committed to keeping certifications up to date?
- Does the software provide for system hardening and performance optimization (such as control-plane policing and system tuning parameters) and system/feature failover options?
- Understand performance trade-offs when enabling several features applied to the same traffic flows. Multiple devices may be required to provide all feature requirements.
- Is the vendor committed to secure coding practices and responsive to addressing vulnerabilities?
After building an ecosystem blueprint, how can we be sure its deployment supports appropriate deployment, design, and security principles? The next blog will look at the role of best practices, industry guidelines, and compliance requirements.
