As the enterprise evolves by leveraging new technologies such as bring your own device (BYOD) and the cloud, security architecture needs to be redefined to remain effective. Many services are moving out to the network edge and beyond. There are security issues that must be considered, as often these are tied to internal systems. These significant changes to the traditional network and security architecture results in the need to go back to the blueprints and develop an agile architecture. Understanding the complex data interactions in the enterprise by developing trust models is a requisite exercise, and will be explained in detail in this chapter.
We will cover the following topics in this chapter:
- The evolution of networks and why the security architecture must change
- Introduction of the data-centric security architecture
- Developing trust models and mapping data interaction
- Considerations for developing trust models for BYOD initiatives
The enterprise network edge has been an evolving infrastructure, as many applications have become web-enabled in addition to the increasing demand for enterprise data from business partners and other third parties. The requirement for access to enterprise data is being driven by the need for the enterprise to outsource portions of their provided services, an example being the calculation of shipping costs for an e-commerce transaction. Traditionally, the sources of enterprise data may have resided in the internal trusted segments of the network, but this is changing with new opportunities provided by cloud-based offerings and collapsed virtualized DMZ implementations.
A newer internal network trend is a "trust no one " model, where the internal data systems are firewalled and protected at the same level as a typical DMZ implementation. In order for the internally secure zone to maintain restrictive access policies, a virtualization technology may be implemented to further control and prohibit direct access to the data. This approach essentially defines the internal user population as untrusted, moving the network edge further into the core of the internal network. A serious consideration of the implementation caveats is recommended, as cost and application complexity may be significant challenges. Let's take a closer look at the business drivers that have changed the definition of the network edge.
There are many reasons for the changes observed in the network edge. Generally, the observed changes are due to new services that require access to enterprise data for both internal and external sources. If we take a step back and think about the evolution of the DMZ, we can recognize the shift from providing a basic Internet presence to providing feature-rich Internet accessible applications, and complex network connections to business partners for sharing enterprise data. An increase in the use of cloud-based services and capital expense savings of BYOD initiatives further complicate and gray the lines of network boundaries. Each of these introduces unique security challenges that stretch our current network-based security architectures.
In order to provide a full-featured web application, permission to access the enterprise data stored in an internal database infrastructure may be required. The typical implementation of an Internet accessible web application positions the presentation and logic tiers within the DMZ infrastructure with the backend data located in the internal network or in a segmented portion of the DMZ. Due to the database relationship, web applications are the primary target for exploitation.
A common attack called SQL injection is used as a method for exploiting a web application misconfiguration, which can lead to direct access to the data resident in the database infrastructure. It is generally understood how SQL injection is carried out, but if reliance is solely on the network security appliances to protect data, it will quickly be realized that this approach to security architecture is flawed. Simply implementing the web application infrastructure within the current standard network and security architecture does not properly address this security issue, however, an architecture focused on data interaction ensures that secure access to data is implemented.
A typical deployment of a web application is two to three logical tiers comprising the web, application, and database components. There are also some implementations where the web and application tiers are collapsed into a single tier. In the latter case, we start to see a deviation from the generally accepted security architecture practices, because there is confusion on where this hybrid web and application instance should reside in the DMZ. To date we have used our network design to determine our security architecture and limit the value of it to restricting protocols and network communication direction.
The hybrid solution could reside in the web tier, bypass the traditional second tier, and connect directly into the database tier, typically located in the core internal network. This type of implementation usually makes the security team cringe. The other option is to place the hybrid instance in tier two of the architecture, but now we have the untrusted Internet and semi-trusted business partners accessing the application tier directly; this again is not ideal. The benefit of user input sanitation, validation, and protocol enforcement is minimized by the lack of firewalled and segmented tiers.
To help facilitate these types of implementations, we often find ourselves making hard decisions to get something to work. We may even decide to move the database into the DMZ or try some method of segmentation with a stateful firewall. Either way, we should be able to discern that we are only manipulating the network aspect of the implementation.
The protocols and communication methods are not modified in this design even though the architecture is. This deviation from the architectural standard circumvents the intended security and leaves us unsure of the risks associated with the deviation. This unknown is counterintuitive to risk reduction; risk is what we are trying to limit with well-developed security architecture.
Another driver for redefining the network edge is business partner access to the enterprise data. Some enterprises have developed unique network zones to handle the network connectivity, but haven't really solved the data location issue because the security architecture is still network driven. Common access is provisioned to the same highly-sensitive segment of the network, where the most critical enterprise data resides to facilitate access requirements. The end result is an internally segmented network that is secured from internal users, but accessible directly from an offsite network that circumvents the internally deployed security mechanisms. This example is extraordinary, as the secure internal segment in this example does not exist across the traditional enterprise landscape.
Here are a few examples of a standard business partner connectivity that enforce a simple security architecture:
The business partner architecture shown in the preceding diagram may look very similar to the DMZ architecture; in concept they are the same. It may be a micro architecture within a tier of the macro architecture of the enterprise. Variations of this architecture may include allowed protocols, destination systems, communication directions, and types of required security mechanisms implemented based on a calculated risk that defines a level of trust. It can be assumed that a business partner will have a higher trust than an anonymous user on the Internet. There are many ways to facilitate the business partner connectivity. I have given an example of a common network architecture where the security of the implementation is an overlay. There are issues with this logic where risk cannot be measured individually for the connections permitted, and appropriate security mechanisms are implemented to differing degrees for risk mitigation.
Access to the enterprise data is many times unavoidable; it may be needed for the enterprise to perform some business critical function or to provide a service enabling function, by allowing the business partner to access the enterprise data. The primary issue is that the enterprise may not have a method where data can be fed to multiple destinations, allowing the data to be served to a solution for business partners. This forces the enterprise to allow access to the most critical systems and network segments, where even the internal users do not have access permissions.
If the scope of a compromise is being considered, I am not sure this is where I would want to connect my business partners into my network. If the business partner is compromised and the threat is propagated over the business connection then the threat can have a heyday in the most secured part of the network. A proper implementation of a security architecture built on a well-defined trust model is the key to a successful implementation of any connectivity to the network, including business partners.
In order for the enterprise to thrive in the global economy, it has become increasingly important to leverage services provided by third parties who specialize in the desired service. As I mentioned earlier, one example is the shipping cost calculation for an e-commerce website. Of course, the enterprise could create a solution to generate this data and store it in a database, but there is an associated overhead cost with this method. Not only would the enterprise have to purchase the infrastructure, build the database, and secure the data, but there is also a significant total cost of ownership based on the operational aspect of the implementation. If the enterprise is not specialized in the desired area, the cost will be significantly more. Having a third party provide the service(s) in a canned manner with an interface into the enterprise application makes much more sense.
The most impactful consideration here is not only the type of data but also where it resides. Because the third-party service connections are much like business partner connections, the same challenges exist with trying to implement per a standard security architecture.
Cloud service offerings are extending the enterprise network to hosted virtualized infrastructure. Enterprise data literally can reside anywhere within the global network of the cloud service providers. Due to cost savings and high availability offerings, a service several enterprises are moving to the cloud is their e-mail implementation. With this relocation of services comes a significant concern over the security of the hosted data.
Enterprises must consider this reality when they consider what data gets moved to the cloud and how it will be protected, not only in transmission but also in storage. An example would be providing data loss prevention capabilities for services that are provided in the cloud. Typically, this would occur on hosts and possibly the DMZ zone of the enterprise network, both of which are no longer in the control of the enterprise in the typical cloud implementation. Information security teams must provide secure access for data, along with providing a flexible architecture to handle the hooks into the enterprise network from the cloud solution. The scope of protection in a cloud solution is well beyond what the enterprise has ever had to solve.