What should you consider as part of a network design?

[phenomlab]

At the heart of today’s communications is a network. Ranging from simplistic to complex, each of these frameworks plays a pivotal role in joining disparate nodes together. But what happens when a design or security flaw impacts the speed, functionality, and overall security of your network ?

What factors create a network ?

A network is a collection of components that, when joined together, provide the necessary transit to carry information from one system to another. The fundamental purpose of a network is to establish inter-connectivity between disparate locations, leverage a mutually understood communication language, and allow traffic to pass over a physical or logical link. The endless possibilities provided by a modern network allows businesses and individuals to communicate seamlessly, allowing for collaboration, communication, and integration whilst providing a centralized model for overall management.

The network has its origins set back as far as the 1960’s, and over the years, various implementations of connectivity standards and the associated fabric dawned and waned. The consolidation of these proposals (known as RFC) created three new standards – Ethernet, UDP, and TCP/IP. These accepted standards now form the underlying foundations of the network we utilize today – both from the enterprise perspective in the workplace and the individual using the internet. Ethernet is the physical medium (a network card, for example), whilst TCP and UDP are the transport protocols, or the common language mutually understood by thousands of vendors.

Adopted standards

These early standards became the groundwork that the internet we know today was built on. Formerly known as ARPANET, and originally developed as a university network, it’s popularity and usage grew exponentially to form the world’s largest collection of interconnected devices, and led to it being nicknamed The Information Superhighway. The birth of the internet became the seed that established the genesis of communication we all now take for granted on a daily basis.

Today’s industry standards dictate how network equipment should be connected together, and with even the most basic knowledge, anyone can connect themselves to the internet in a matter of minutes. This ease of configuration and deployment means businesses and individuals can be online within a short time frame – albeit using an “out of the box” design, and with little (if any) consideration for security or risk.

Security implication

The security implications of any network are a constantly moving target. New vulnerabilities are discovered in vendor equipment on a daily basis, and with some of these vulnerabilities being resident since day one (but either undiscovered or undisclosed) , planning for every possible scenario isn’t feasible – particularly if you have limited resources. When designing a network, it’s important to implement a means of limiting the attack vector. Whilst this sounds very complex, to a seasoned network architect, it isn’t. Essentially, what you should be doing is creating a jail based environment for each network segment.

Think outside of the box at this point – the general application of inside, outside, DMZ etc no longer provide sufficient scope if an attacker has made it onto your internal network. For example, take two departments, such as accounting and operations. How likely is it that these two entities need to share information or communicate directly at a PC level ? With this in mind, an accepted standard is for each department to reside in it’s own VLAN. Using industry defined ACLS, each department cannot communicate directly with another. They do, however, have access to the server VLAN - although this should also follow a similar security regime of only permitting access to essential services - in other words, adopt the least privilege model.

Whilst this sounds obvious, most network designs do not factor in this basic requirement. By “segmenting” each department, you establish a boundary between each of them. This means that if malware were to be installed on a PC in accounting, it would not be able to infect a machine in operations, or HR. Containerized network designs are secure, but not perfect. In the event of a PC being infected with malware, the VLAN it resides in still has access to the servers and other associated infrastructure that the client needs in order to perform it’s desired function. In this case, you would also need to only permit access to critical or essential services. The upside of such an approach is that the implemented network security means that a malware or ransomware attack is limited to infecting a small number of machines rather than the whole network. The downside is that there is an initial overhead in terms of discovery, implementation, and testing. In my view, however, the dividends outweigh the effort.

Balancing security against functionality

Securing the server VLAN can be problematic. Establishing a balance between over gratuitous and insufficient connectivity is the ultimate headache. At this point, you need to consider what resides in this network segment. In essence, it’s the business equivalent of the crown jewels - the critical components of your entire estate. This “no fly zone” contains a wealth of information that is of interest and value to a cyber criminal. Assets such as intellectual property, financial data, and personally identifiable information are all a potential target in the event of a data breach.

If you consider the role that servers have, you’ll probably find that most of them really should not have (or even need) raw access to the internet. There are always some exceptions to this rule, but one of the first target areas to consider is the level of access to the outside world granted to a server. Even a server using NAT to communicate with an external host is at risk of compromise. From the network perspective, establishing a remote connection is just the start of a series of conversations and negotiations between the two endpoints. The main differences between TCP and UDP is that one waits for a response to a connection, whereas the other does not. UDP is a fire and forget protocol, making it ideal for DNS, SNMP, SYSLOG, and a wealth of other applications. TCP on the other hand will wait for a response from the remote host before continuing with the session. A lack of access in or out of a VLAN is not an attractive prospect for even a determined hacker.

Using various techniques, a cyber criminal can intercept the TCP headers to inject malicious content or payload, or masquerade as the remote host by means of a TCP redirect. This means that the network you are connected to may not be what you expected or desired. Packet sniffing is very easy once you have an understanding of how products such as WireShark function (an exploit known as eavesdropping). In order to significantly reduce the possibility of attack, only servers that have an essential requirement for an Internet connection in order to fulfill their designated function should be permitted access – even then, it should be only to the ports and IP addresses required, and nothing else. It goes without saying that industry standards should be adopted and adhered to – requests should be via a firewall with IDS and IPS capabilities. These devices have the ability to look at a network steam and determine if it has been tampered with. If the hashes do not match, or there are signs of modification not requested by either party, the session is destroyed (if using IPS) and an alert raised. This functionality can be dramatically altered by misconfiguration, so check thoroughly.

Vulnerabilities generated by older firmware

Devices running inferior versions of firmware are subject to compromise and potential exploit – particularly if they are edge based routers that are accessible from the outside world. Older versions of firmware on exposed routers can pose a significant risk to your perimeter and internal networks if vulnerabilities are not located and resolved quickly. A vulnerable router on a network can easily become an infiltration and extraction point, and you could find yourself the unwilling target of a data breach.

On the whole, adequate network design not only takes redundancy, scalability, and availability into account, but also security and stability. A classic example of failure to address the latter is the difference between your network standing up to a DDoS attack, or still being functional with only one VLAN or segment impacted. The days where we only made provisions for disaster recovery and business continuity are over. Security needs sound investment and knowledge in order to understand principles and apply standards correctly.

Takeaway

I’m not into preaching to others about how they should be doing things from the networking perspective, but my basic advice would be

• Carefully plan any new network implementation in advance. Visio and whiteboard sessions are important when thrashing out ideas, as an overall picture of the landscape is generally easier to digest than just text.
• Involve peer groups and key individuals from the outset. Everyone has their own unique insight as to how things should be structured, and just because it works for security, or the model you are developing, it may not necessarily work for the business as a whole
• Be prepared to make changes to the design, and by definition, listen to business advice. Nobody creates the holy grail of network concepts and implementation on their first attempt
• Unless you are blessed with a green field site, make a point of understanding the existing infrastructure and architecture, and design a mechanism for coexistence between the two environments.
• Be mindful of the potential for conflicting standards when dealing with different vendor equipment, and also consider that security could be negated in the existing environment whilst the integration process is underway.

These are just a few of the points – there are many others. Want to know more, or have questions ? Just ask