In concept, securing the enterprise may seem like a binary statement or universally understood idea, but a common solution continues to elude us. We have been trained to think that if we take certain steps such as developing secure processes, providing security training, and implementing security technologies, then we have secured the enterprise. This is in fact the "façade" of today's enterprise security approach. Security is not binary in an enterprise and implementation should be approached with a flexible and agile security architecture based on risk to enterprise data, therefore making the implementation of security more gray than black and white.
The static and inflexible approach meets compromise when a solution does not fit into the defined security architecture introducing undesirable risk, followed by the fall of idealistic enterprise security. In order for us to get to where we need to be, we need to understand the façade of enterprise security and take a look at how we got to the idea of enterprise security that is driving security purchases and the security industry today.
In the earliest enterprise networks, there was not much call for a DMZ due to there being no real Internet presence like today. One example of early networking that drew the attention of malicious users was enterprise dial-up networking connections. Modems were used to make outbound calls and accept inbound calls to primarily process batch jobs for large backend systems. Security of this implementation was not much of a concern because the phone numbers had to be known and the systems connected to the modems were expecting very specific data from the calling modem. Eventually, modems became the method used by network and system administrators to connect to the enterprise network remotely for support functions. This was an excellent out-of-band method to access critical network infrastructure. If security was enabled, there may have been DIP switch settings that enabled password security on the receiving modem. This was until war dialing became a method to identify modems in large banks of phone numbers for attackers to gain unauthorized access to the connected equipment or network.
Note
War dialing is a method of dialing large pools of phone numbers looking for a modem attached to gain unauthorized access to a network. Non-local calling was expensive so this led to hackers exploiting Private Branch Exchanges (PBXs) using a method called phreaking. Phreaking is a method of sending tones through the phone to the PBX that tricks the PBX to allow the calls for free.
Specialized equipment was designed and sold to enterprises to provide security for the modem infrastructure. As more advanced networking technologies were developed and enterprise assets became accessible on the Internet, weaknesses in the systems and network security were quickly identified. Attackers were eager to exploit any vulnerability that was discovered. This behavior influenced network equipment manufacturers to begin developing security products to defeat specific security threats as they were identified. Point solutions were chosen not accepting that this was a "band-aid" approach that would fuel a narrowly-focused security industry.
As more threats were observed, more point solutions were developed to mitigate the threats. It was this natural progression of networking capabilities and threats that launched the security software and hardware manufacturing industry of today. We have continued this pattern of reaction-based development of security tools driven by mitigating specific threats as they are identified. In lockstep, we implemented the new technology to protect against the new "threat". Anti-virus, firewalls, intrusion detection/prevention, and other security technologies are the direct result of an existing threat, and are reactive.
Our efforts had been focused on securing the infrastructure and we forgot about the data, applications, processes, and users. It is easier to just buy the new technology of the day and support the illusion that we are secure from the "threat". This is the trend today. Advanced persistent threat mitigation became a hot topic because it became a real threat and instead of rethinking our security architecture, we purchased and implemented another technology, and probably implemented the solution at the network perimeter. This should seem familiar. We bought the story the security vendors had to sell. If there is a threat, buy our product and it will make you secure.
The next diagram shows the progression of point solutions being developed over time as new threats are detected. It also shows that detection and mitigation of threats becomes more complex over time as the threats themselves become more complex. As Threat 1 is identified, then Product 1 is developed to specifically mitigate Threat 1, and so on. We are seeing some traction in hardware and software that is capable of mitigating several threats. However, integration, management, solution scalability, and ability to provide deep coverage in all areas is yet to be seen. This continues the trend observed to date.
Having observed the history of enterprise security and the status quo reaction, we didn't realize we were buying into a false thought. So we implemented poorly-integrated security controls to address the enterprise's need to secure its assets while allowing business to continue. Unfortunately, what we designed was a relatively secure network perimeter instead of functioning, extensible, enterprise-wide security architecture. In fact, most developed security architecture is sound network design with an overlay of security that dictates what communication is allowed to and from the unique network zones.
Whether it is called a DMZ, a business partner zone, or a remote office zone, it is perimeter security by design and function. Until recently this made sense; though not true, it was thought that the known threat has always been external. Networks may have been large, but not overly complex, with multiple business partner connections or multiple DMZs. Typically, if there were services to be made available to an outside entity, we would place the assets providing the service in a perimeter zone, give it a name, and implement according to a defined security architecture. Such was the extent of implementing a secure solution.
This mentality has led to bloated security budgets, crowded perimeter zones, and very little increase in security. Because we have purchased and implemented the latest next-generation firewall technology, intrusion prevention systems, advanced persistent threat mitigation, data loss prevention, and file integrity monitoring, we think we have secured the enterprise. However, we have only increased the complexity in mitigating low-hanging fruit threats at the network perimeter and decreased our effectiveness in mitigating threats holistically. This is the security façade we've jointly created with our security software and hardware manufacturers.
We as a security industry have found ourselves in a unique position with significant changes in the way enterprises are conducting business. The late 1990s solidified the Internet as the premier method to market, provide services, and sell products in a global economy. This also meant that to be competitive, outsourcing of internal work would occur, remote access to critical systems was required, and more complex applications would be implemented with access to the most critical systems and data. This changed the threat landscape. Our focus became more on protecting all external threats, while losing focus on the most risky access we so quickly gave away, so that the business could grow.
In order to have a consistent approach to security, security architecture must be defined. Enterprise security architecture is the blueprint for securely implementing enterprise solutions to meet business requirements. Much like a house has blueprints for properly constructing it, security architecture serves the same purpose for the enterprise security design and implementation.
Up to this point, we have been discussing the implementation of security technologies as point solutions not necessarily as part of a defined security architecture. The progression of network technologies and business drivers created the first security architecture, but it was network focused and failed to address the enterprise as a whole taking into account data, processes, applications, roles, and users. Implementing to the network-based architecture with a security overlay limits the ability to sufficiently secure these components of the enterprise with agility and flexibility.
The current "security" architecture addresses user access to data in a very generic manner, focusing primarily on what protocols can be used at what tier of the network regardless of who the user is, the application used, type of data, and data interaction. An example of this approach is shown in the following diagram:
If the approach for securing the enterprise is to constrain all solutions the enterprise implements into this defined "security" architecture, then there will be three possible outcomes:
Implementation in accordance with defined security architecture; there is no deviation from design or defined security architecture
Implementation in accordance with security architecture cripples the solution and implementation of the solution is aborted
Implementation not in accordance with security architecture weakens the effectiveness of the security architecture to make the implementation successful and introduces risk to the organization
This inflexible security architecture often requires the enterprise to quickly decide if the "risk" of not following security architecture is acceptable or if another method is available to secure the implementation without jeopardizing the project (investment on the table). By risk, I am presenting the fact that this is usually a determination of whether properly securing the implementation is too costly and difficult versus accepting the perceived risk and proceeding with the implementation. To reduce the risk associated with not following the architecture, compensating security mechanisms may be implemented. A continued cycle of this resolution leads to an overall less secure enterprise.
Let's look at an example of our current method of implementing security in line with our common and generic security architecture. Today, we have done a good job at creating segmented networks at least at the network layer using virtual LANs (VLANs), internal firewall segmentation slowly being introduced, and assigning our users to groups according to job functions. I am careful to imply we have commonly defined roles within our architecture, so I will use functions, usually no more than a team designation. An example would be a VLAN called DBA_VLAN that is for the database administrator job function. Each VLAN will have its own unique IP subnet, so the database administrator "team" can easily be identified by the IP address of their system on the network. We can then implement firewall rules (if implemented) to allow this unique IP subnet access to the systems with databases. This is a very simple implementation and very ineffective security. In this previous example, the only unique identifier is the IP address in an assigned IP subnet belonging to the database administrators. This method does not constitute a secure authentication method, which should be more granular and performed at the user level.
The teams responsible for the security of the databases would present that the database security itself is the most important, so it doesn't matter who is sitting on the DBA_VLAN because ultimately only authenticated individuals can access the database systems. Unfortunately, this architecture allows for many misuse scenarios that increase the risk of a data breach through unauthorized access over trusted communications. We may have implemented security mechanisms, but I am willing to bet they are threat specific and lack the broader threat perspective required to secure the implementation. This is not security architecture, it is security patchwork often focused only on the product side of security because we have never figured out how to properly secure our people through roles, processes, policies, and standards. The example presented is the unacceptable yet accepted norm; recent data breaches have proven this is not a sufficient method to secure data.
Our approach to securing the enterprise should go beyond simple threat mitigation. After all, this is exactly why we are in the not-so-effective security state that causes the breaches we see regularly in the news. As with all good design and architecture there are many factors that must be taken into consideration to properly influence the correct implementation. There is network infrastructure, system architecture, applications, and data that need to be designed, implemented, and secured. There are also people and systems that will access these components provided by the enterprise to use a service, and so on.
I recently traveled to Savannah, Georgia (GA) and was able to appreciate this very principle in home and building architecture and design. Did you know that any home built in historic Savannah has to be externally period correct? The requirement is to maintain the well-thought-out and aesthetically pleasing architecture. The original architects had many influences and deep reasons for the materials, layout, functionality, and design of the buildings at different points in history. Each home and building was not approached with a single thought or idea for its only purpose; instead, there is a standard that must be followed. The architectural standard allows the construction of new homes with modern amenities inside, but the exterior must fit it to the surroundings. Owners of the homes can decorate the interior how they please; this is the uniqueness of each home allowing each home owner to have the home they want without introducing architectural anomalies to Savannah. As architects design and plan a new home build in Savannah, GA, we should approach security architecture with the same broad, yet focused vision in the enterprise.
With the previous database system access scenario fresh in our minds, what would be more of an architectural approach? First, should security architecture rigidly define how this access should be granted, or can a more flexible approach be leveraged? I think the best first step would be to back up and take a broader look at the requested access. If we can understand the criticality of the data/system based on the data or function, what type of access is needed, why the access is needed, who or what will access the data/system, then we can determine the risk and better develop an architecture that properly secures the data/system and provides the access needed to allow the business to function. The issue we most often run into is we jump right into figuring out how we are going to secure something, whether it is networks' communications, system access, or whatever, without any idea what (if any) risk is introduced. The other issue is, since we have focused so much on securing the DMZ, we haven't properly architected security further into the infrastructure, at least not more that the typical firewall, IDS/IPS, and maybe some system security products, so we are forced to either make expensive purchases or compromise on security.
Unless we develop a new security architecture—an architecture that addresses all facets of security and provides a realistic picture of the risk posed by any implementation—the secure enterprise will never be realized. The new approach to security architecture takes into account data, processes, applications, user roles, and users, in addition to the traditional network security mechanisms to provide end-to-end security from entry to the network to the data resident within the enterprise. The following diagram shows a more comprehensive approach to security based on risk of the entire interaction with enterprise data:
