The road to a risk aware secure enterprise does exist; it is challenging, but tangible. In this section, I will lay out a road map to developing flexible security architecture as the foundation to securing the enterprise. It is not the only method, but it is sound and will hopefully serve as an exercise to challenge enterprise security teams to rethink the current architecture and security methods being implemented.
There are several exercises that must be completed to obtain an accurate representation and definition of the enterprise assets (systems, data, and so on), communication methods, users, roles, business processes, policies, and standards. Each will need to be defined in extreme detail to be most effective, but if this is the first attempt a more generic definition of each can be the starting point, with a gradual increase in detail, until everything is defined and all possible combinations identified. The road map provided is an introduction to the detailed approach in the next chapter.
Starting with user groups may be the easiest, however, you can focus on systems and data in the beginning phases, especially if there has been absolutely no data classification or critical system identification. All of this data will serve as input to the trust models we will develop in the next chapter. Here we will provide an overview of what should be collected for each defined component. It should be noted that all components need periodic review, and recertification should be built into the process. A simple diagram of the process at a high level is provided as follows:
All users within the enterprise and those that interact with the enterprise, such as contractors and business partners, must be identified and their relationship with the enterprise determined. This data will provide input to roles and start tying the relationship of an individual or group of individuals to data.
Define all applications in the enterprise, their purpose, and what data they are used to access. It is also important to understand what systems the applications are installed on to determine scope when identifying risks associated with application access.
This may seem very simple, but it can prove to be a difficult task even for the smallest enterprise. Each department may have different data, and subjectively valued, it may not be defined in the perspective of overall value to the enterprise. Additionally, identifying where the data resides, such as which systems or physical locations, is a key issue. Things to consider are duplication and backups of the data. Data may reside in desktop applications such as Microsoft Access with databases duplicated many times over for each user that needs access residing on the user systems. Additionally, data should have a classification assigned per policy that dictates the required security for the identified data and may need to be in compliance to HIPPA, SOX, PCI, and other regulatory requirements. Data is the focus, as typically systems have no value aside from the expense of the physical hardware and the data that is contained within them.
Once users and data sets have been identified, the purpose of the access must be defined. For instance, basic user access versus administrator access. There are also data custodians; perhaps our trust model will have additional monitoring requirements based on the level of access to critical data. These roles can start as generic, but the more defined the user group and roles are, the better the user interaction will be understood and the more granular the controls that can be implemented.
Defining business processes will often lead to identification of the business critical data and systems. Understanding the processes that make the enterprise function can also identify additional users and roles not previously identified. Examples of processes are automation, change management, and third-party oversight.
Once all users, roles, and processes have been defined, there must be some policy that dictates what is permitted use of the authorized access, and defines what is unauthorized behavior while using the enterprise assets including but not limited to: network, applications, systems, and data. Standards by which users are to be provisioned, access to applications, data, and systems to be handled should be standardized to ensure consistency. Standards will also include items such as system builds and security, security configuration of applications, and security monitoring.
It is important that the enterprise is willing to take action if there is a violation of policies and standards because it is implied that deviation from these will introduce risk to the enterprise and possibly undermine security, resulting in a data breach or other negative impact to the enterprise.
This process requires understanding what has already been implemented to facilitate business partner communications, external access via website, VPN access, and so on. Having defined the network "zones" and the users, both internal and external, that use them will drive the required security monitoring and protection mechanisms. In some cases once this exercise has been completed, it may be determined that a new zone needs to be created and implemented to support the security initiative of the organizations.
A layered approach to security that includes network infrastructure is critical to an end-to-end secure enterprise. Ultimately, the preceding component definition should drive much of the network architecture, where applicable, requiring the network and security teams to work closely in these areas of the infrastructure. There must be consistent standards, especially for the network infrastructure, as it provides all the connectivity for business network communications.
Applications are the preferred method for accessing enterprise data. Understanding how security is integrated into applications through a formal Software Development Life Cycle (SDLC) will not only provide useful data for trust models, but may also highlight other areas that need additional security implemented to meet the standard of the application. Standards for data protection can be gleaned from the secure development processes that can be used in other areas of IT.