The strength of any system is only as strong as the weakest link; in the case of technology, humans are the weakest link. We are in the information sharing age where data is everywhere, available, and systems can be accessed all over the network and Internet; but this comes with a cost. Access to data and systems can lead to unintended consequences especially if the access is not necessary. This is common for the enterprise data center. All data center assets are available over the network. Though application access may be limited, this does not stop all threats to the data accessed through the applications or that which resides in databases and network shares located in the data center. The need for accessibility has overridden the integrity and security of enterprise data leaving it vulnerable to whatever or whoever finds a way onto the network.
In our trust model paradigm, a careful examination of the present processes, applications, and users that need access to enterprise data must drive our definition of roles, trust, and protection mechanisms required to secure interaction with the data. Because this is not the normal process used to develop data access controls, enforcement of least privilege is many times non-existent. If the access being requested does not adhere to defined access policies, then it should be denied until the requesting access is properly designed and configured to reduce the weakening of the data security posture.
Initiatives such as Bring Your Own Device (BYOD) highlight the need to fiercely restrict general and direct access to data to only those which have the correct trust. Virtualization is a technology that is an excellent example and method of achieving this level of access control. It will not matter what device is on the network if the only devices that can touch the data are enterprise owned, secured, and monitored. Hosts that are compromised will not have direct access to assets of value—ideally no enterprise assets— and limited only to their own segmented switch port that provides IP addressing and access to a virtual environment.
Until this paradigm is accepted in the enterprise, there will be continued malware outbreaks, system and data breaches, and loss at the hands of the humans who use the network and access enterprise data. It is not a right to have access; it is a privilege, and privileges should be given only when certain conditions are met, as defined by the enterprise trust models. It should be acceptable and common to deny access to critical data and systems when access requires a weakening of security; "temporary" access should not be considered. Significant investment is made in security and senior-level support is needed to ensure new solutions and enterprise initiatives are purchased and developed with security as a key component. If this does not occur, it is best to prepare for data loss and compromise.
The next sections cover the unique roles that system, application, and database administrators play in the enterprise. These roles have elevated access privileges to sensitive network areas and high-value assets. With this access, there is great responsibility and a greater need to enforce least privilege while operating in a multi-tenant situation. The first section provides an overview of administrator-level access with the subsequent sections covering the system, application, and database administrator in detail.
The role of an administrator, by definitions is the individual or team that is officially responsible for the system, application, or process of which the responsibility is given. This is a significant responsibility and possesses authority and access to the entity in its entirety. Because of this overwhelming ability to see all and do all, the access should be monitored and implemented in a fashion to reduce the unnecessary compromise of all components within the technical sphere of control of administrators. Therefore it is further necessary to segregate where possible and define territories of control, access, and ultimately, responsibility.
Systems in any enterprise will require an administrator account or group to properly maintain the operating system and installed software. True ownership of a system can be rather convoluted in the common enterprise where one team owns the hardware and OS and another team owns the application(s) and related data. To further complicate the matter, in instances when the system is a security system, administrator access becomes a significant matter to address.
Administrator access is based on the role of the administrator (system, data, or application) and must be implemented in a manner that enforces separation of duties by limiting access to view and modify the other components that may be resident on a single system. In addition, to control access to other components within the context of the role, least privilege should be the guiding principle for access provisioning. To ensure continued security of administrator credentials, the password should be changed at least every 45 days or when an administrator group member leaves the enterprise or changes roles.
A necessary role within the enterprise is the system administrator ; usually a team within IT that is responsible for all system hardware and operating systems implemented. The role may also include software management on servers and end user systems within the organization. The system administrator is the most privileged account on any system (root for *nix-based systems); but for simplicity, system administrator will be used in this text. This elevated access allows potential access to data that resides on the system that is beyond the scope of the administrator role and must be limited to enforce separation of duties and confidentiality of the data. The system administrator must not have access to anything other than the OS and software packages where an agreement exists between the system administrator and the application owner.
System monitoring must be in place to ensure the defined roles are enforced especially when there is no technical capability to do so. All system administrator access should be logged, reviewed, and corrective action taken if necessary. A method to ensure individuals are accountable is to assign unique login credentials for each system administrator. Tasks that are general in nature such as automated patching may use a service account that does not permit interactive login.
As presented earlier, specialized security awareness training should be developed for this unique role within the enterprise to communicate the acceptable and expected behaviors of the system administrator. Because this role typically has elevated privileges across the enterprise, training on targeted social engineering for system administrators is advisable as they are prime targets for a malicious hacker to exploit for expedient data access.
Data administrators or data custodians are ultimately responsible for the data in the enterprise for a given application or process. The availability, confidentiality, and integrity of the data must be controlled and maintained by the data administrators and only the data administrators. All access to the data and how it is used must be through a formal process and must not be a result of inherited access, nor residual access due to a lacking access removal process. The data administrator must be able to speak to any modifications, deletions, or other interactions with the data they are responsible for maintaining.
In most cases, the data administrator role is the responsibility of the database team because most data in storage for applications and processing resides in some form of database. Though it may be more difficult for a system administrator to gain access to data, the database team has direct access on an almost constant basis. The daily tasks of the database team consist of building databases, testing, and maintenance activities all of which should be monitored, logged, and peer reviewed.
Also, much like the system administrator, the database administrator is a prime target for malicious hackers to more easily gain access to enterprise data. It is much easier to social engineer a database administrator than to penetrate a well-secured network. Special security awareness training should be written and communicated to this highly important team. Some of the largest breaches have been phishing attacks targeted specifically at the team who has the most access to enterprise data: the database team.
The role of application administrator is to define and manage roles within the application, application maintenance, and application user provisioning. The administrator may or may not need access to view, modify, or delete the data accessed by the application and will be a case by case implementation. Typically, the application is the interface to the data residing in the database, process, or application, and therefore role assignment is critical to the overall security of the resident data. The application administrator must manage any and all access to data through the application by placing users into the correct roles based on the requirement for access. Leveraging the defined trust models and mapping users to available roles will ensure consistent implementation across applications.
This role may have more or limited access to enterprise data depending on the configuration of the application and how it interacts with data. Being a step back from the data store (database), there is technically a limit to the interaction with data and many times it will be the application accessing the data, not a user or administrator of the application. It is a good practice to log all application access and actions to ensure this assumption remains true. Though it can also be assumed the application administrator will have the most application access: changes to the configuration of the application, added users, and permission changes should be logged, monitored, and reviewed for legitimacy.
Although the application administrator is not the most privileged user with access to enterprise data, there is enough interaction to ensure this interaction is acceptable. Developing specialized security awareness training for this team can reinforce the need to ensure least privilege, and as needed access to data interacted with by the application. Again, this team is a prime target for malicious hackers and will many times be exploited to gain credentials, access to data, and other systems to attack. Keeping this team aware of this potential will hopefully keep them sharp on account review and other application behaviors indicative of compromise.