Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Extensible Authentication Protocol wikipedia , lookup
Computer security wikipedia , lookup
Distributed firewall wikipedia , lookup
Zero-configuration networking wikipedia , lookup
TV Everywhere wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Wireless security wikipedia , lookup
STI JOINT WRITTEN PROJECT ARCHITECTURE DESIGN FOR GIAC ENTERPRISES DEFENSE IN DEPTH USING ROLE BASED ACCESS CONTROL Version 1.7 May 25, 2017 Team: Russell Meyer, Brad Ruppert Developed for www.sans.edu SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth Revisions Version Primary Author(s) Description of Version 1.1 Brad Ruppert and Russell Meyer Initial development of architecture and background of RBAC Defense in Depth 09/05/2007 1.2 Brad Ruppert Added content for RBAC in DMZ and internal systems 9/07/2007 1.3 Russell Meyer Added content for RBAC use within the network, segregation of duties, and infrastructure 9/11/2007 1.4 Brad Ruppert Formatting, TOC, error correction 9/11/2007 1.5 Russell Meyer Updates to NAC slide and Audit slide 9/12/2007 1.6 Russell Meyer Expansion of MetaFrame, and Networking components 9/14/2007 1.7 Brad Ruppert Grammatical changes and Vintela expansion 9/17/2007 582816547 (05/25/17) Date Completed Page 1 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth Contents 1 INTRODUCTION ...........................................................................................................4 1.1 OVERVIEW ................................................................................................................4 1.2 NETWORK DIAGRAM .................................................................................................4 1.3 ASSOCIATED HARDWARE/SOFTWARE .......................................................................5 2 BACKGROUND .............................................................................................................7 2.1 WHAT IS RBAC ........................................................................................................7 2.2 HISTORY OF RBAC ...................................................................................................7 3 RBAC FOR GIAC ENTERPRISES ...............................................................................9 3.1 RBAC ON A SMALL SCALE .......................................................................................9 4 PROTECTING THE DMZ ...........................................................................................11 4.1 ARCHITECTING THE DMZ .......................................................................................11 5 SECURING THE INTERNAL SYSTEMS ........................................................................13 5.1 ARCHITECTING THE INTERNAL ENVIRONMENT .......................................................13 6 RBAC FOR NETWORK DEVICES ..............................................................................15 6.1 RBAC FOR NETWORK DEVICES ..............................................................................15 7 RBAC FOR INFRASTRUCTURE .................................................................................17 7.1 RBAC FOR INFRASTRUCTURE .................................................................................17 8 RBAC FOR SEPARATION OF DUTIES........................................................................18 8.1 RBAC FOR SEPARATION OF DUTIES .......................................................................18 9 RBAC FOR AUDITING ..............................................................................................19 9.1 RBAC FOR AUDITING .............................................................................................19 10 CONCLUSION ...........................................................................................................20 10.1 CONCLUSION .........................................................................................................20 11 REFERENCES ...........................................................................................................22 11.1 REFERENCES .........................................................................................................22 582816547 (05/25/17) Page 2 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth Figures Figure 1: Network Diagram of GIAC Enterprises .................................................................... 4 Figure 2: RBAC Defense in Depth ........................................................................................... 6 Figure 3: Background on RBAC............................................................................................... 8 Figure 4: RBAC Specific to GIAC Enterprises ...................................................................... 10 Figure 5: RBAC in the DMZ .................................................................................................. 12 Figure 6: RBAC for Internal Systems ..................................................................................... 14 Figure 7: RBAC for Network Devices .................................................................................... 16 Figure 8: RBAC for Infrastructure .......................................................................................... 17 Figure 9: RBAC for Separation of Duties ............................................................................... 18 Figure 10: RBAC for Auditing ............................................................................................... 19 Figure 11: Conclusion ............................................................................................................. 21 582816547 (05/25/17) Page 3 Meyer & Ruppert, 2007 STI - Joint Written Project – RBAC Defense in Depth SANS Technology Institute 1 Introduction 1.1 Overview This presentation will outline a defense in depth approach to implementing Role Based Access Control (RBAC) for GIAC Enterprises. GIAC Enterprises is defined in Peter Vestergaard’s paper titled “Firewalls, Perimeter Protection, and VPNs Practical Assignment.” 1.2 Network Diagram Internal PBX DNS DMZ DC/NTP Server Internet IPS External Users Email Server Antivirus Server IPS Email Server Internal Users Wireless Access Point Print Server HR Server File Server Web Server DB Server App Server Web Server Metaframe Presentation Server Figure 1: Network Diagram of GIAC Enterprises Note: The network has been upgraded to reflect a more secure and modern architecture. 582816547 (05/25/17) Page 4 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 1.3 Associated Hardware/Software Hardware Component Operating System / Application Server Domain Controller, Domain Name Server Windows 2003, Active Directory Internal/External Web Server Linux, Apache Int/Ext Email Server Windows 2003, Exchange 2007 Int/Ext IPS Server Cisco 4200 Series Internal File & Print Server Windows 2003 Database Server Windows 2003, SQL Server 2005 Application Server Linux, Weblogic MetaFrame Presentation Server Windows 2003, Citrix Router Cisco 1800 Firewall Cisco PIX 500 HR Server Windows 2003, Peoplesoft Antivirus Server Windows 2003, Symantec Users Workstations Windows XP, Office 2007 582816547 (05/25/17) Page 5 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth RBAC defense in depth for GIAC Enterprises GIAC Enterprises is a small company that sells fortune cookies over the web The company is comprised of a CEO, CFO, Sales Manager, Product Manager, Developer, and System Admin Most of the every day work (producing, selling and marketing) will be done through external partners, which is why the headcount initially is rather low. Considering many partners and suppliers will need access to company resources, it becomes increasingly important for the perimeters to have tight security. The network consists of 14 servers DMZ (Web, MetaFrame, IPS, Email Gateway) Internal (Email, DC, DNS, Web, App, DB, Antivirus, File/Print, IPS, HR) Sales staff has access via MetaFrame to internal network Figure 2: RBAC Defense in Depth 582816547 (05/25/17) Page 6 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 2 Background 2.1 What is RBAC Role Based Access Control (RBAC) is a means of assigning permissions for specific operations to certain roles within an organization. Roles can be assigned to users, groups, and objects which provide a layer of abstraction and thus enables administrators to manage large groups of users and systems with relative ease. 2.2 History of RBAC “The concept of roles and role-based access control (RBAC) has been with us for more than a decade, but enterprises still struggle with implementation of a role-based model on a wide scale. Many projects have failed because of high cost, scope creep, lack of business unit support, and lengthy implementation time lines. But a more generic abstraction layer can be utilized to manage users and their access to resources. Efficient and timely administration, a consistent access management model for resources, and scalability to manage growing user populations are strong drivers for IT administration staffs to explore role-based models.”1 1 Gerry Gebel, Roles and Access Management: Seeking a Balance Between Roles and Rules, Burton Group. Jun 2003 582816547 (05/25/17) Page 7 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth Background on RBAC Role Based Access Control (RBAC) is a methodology of limiting access to objects based on permissions assigned to a specific role Roles can be synonymous with job duties or functions and can be associated with individual users or groups These roles can have permissions associated to systems, files, folders, and other objects within an enterprise The goal in role development is to determine all the permissions in advance that a user might require to perform a specific task or job function and bind these permissions to the specific role Scalability and efficiency gains are two significant benefits of rolebased administration, allowing fewer system administrators to manage higher volumes of users and resources Figure 3: Background on RBAC 582816547 (05/25/17) Page 8 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 3 RBAC for GIAC Enterprises 3.1 RBAC on a Small Scale Having limited resources, some companies may overlook the importance of clearly defined roles and responsibilities. Business continuity as well as future business expansion relies heavily on documented process and the ability to outline job function. RBAC supports this model by creating roles for users/groups and associates permissions to these. This provides greater ease of administration when users come aboard, transition, or exit the company. “Due to the labor resources required and the limitations of most administration tools, organizations are increasingly recognizing the futility of managing access to resources on an individual user basis. The solution to this dilemma begins with the user registration process and the initial assignment of profile information. Organizations can categorize or profile users via static and dynamic groups, role assignment, rule-based attribute processing, or digital identity. Initiating this process early in the user management lifecycle enhances the value of identity information for downstream processes such as user authentication, resource authorization, and implementation of external security domains that use portable or federated digital identity.”2 2 Nick Nikols, Gerry Gebel, Identity Lifecycle Management, Burton Group, Feb 2006 582816547 (05/25/17) Page 9 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth RBAC for GIAC Enterprises The small scale of GIAC Enterprises is both a plus and minus for implementing RBAC Smaller companies will most likely mean users will be assuming multiple roles within the organization thus making it difficult to create static roles for each users or process. Example: initially the domain admin may be the DBA as well depending upon the size of the IT department. Once the company can support additional staff, roles should be defined that separate developer from production support. At first glance the implementation of RBAC in a company with under 10 employees may seem simple. If roles are not properly identified and categorized, scalability becomes a problem. The sooner you can implement principles of least privilege and segregation of duties, the more reliable your process will become. At a high level GIAC Enterprises can be broken into four divisions Business (CEO, CFO, Sales Manager, Product Manager) Development (Developer) Administration (System Administrator) Audit (External Resource) Figure 4: RBAC Specific to GIAC Enterprises 582816547 (05/25/17) Page 10 Meyer & Ruppert, 2007 STI - Joint Written Project – RBAC Defense in Depth SANS Technology Institute 4 Protecting the DMZ 4.1 Architecting the DMZ The DMZ will provide the middle layer between the internal network and the internet and will be enclosed by a firewall on each interface. This area will contain the email gateway, external web server, MetaFrame presentation server, and an intrusion prevention system. The role-based access control over these systems will be managed by a combination of Windows Active Directory (AD) and Vintela Authentication Services (VAS). Vintela Authentication Services (VAS) works as a plug-in to Windows Active Directory and enables cross-platform identity integration and authentication. VAS provides a seamless extension of the security and compliance of the Microsoft Active Directory infrastructure to Unix, Linux, and Mac platforms and applications. It addresses the compliance need for cross-platform access control, the operational need for centralized authentication and single sign-on, and enables simplified, heterogeneous identity management. MetaFrame is the name for a thin client/server software application from Citrix that is used to provide Microsoft's Windows Terminal Server product (WTS) with additional server and client functionality. It accomplishes this by allowing any client, regardless of operating system (OS), to connect to a Windows Terminal Server and run a Windows application through an internet browser. MetaFrame features a secure encryption option through a distributed Windows presentation protocol developed by Citrix, called ICA (Independent Computing Architecture). Employee access to internal systems from the internet will be routed through a MetaFrame presentation server and their authentication and authorization will be verified against Windows AD. Business partners will be routed through our SSL web interface (Apache on Linux) in order to access our production database (MS SQL on Win 2003). All communication between our database and web server will be managed by our application server (Weblogic on Solaris). Authentication will take part via a java-based Single Sign On component of VAS. Vintela will be a component of our Active Directory backbone which will be used to manage access controls around the roles of users/systems/groups. The Cisco IPS device will be self contained and managed by our system administrator. 582816547 (05/25/17) Page 11 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth RBAC in the DMZ The DMZ houses the Email gateway, IPS, Web Server, and MetaFrame Presentation Server Windows systems (Email, MetaFrame) use Active Directory (AD) for maintaining rolebased access controls Linux systems (Web, App, IPS) use Vintela Authentication Services (VAS) which sits on the AD framework for administering role-based access controls Within AD, the following roles are defined specific to the DMZ: User - read-only access to web pages Administrator - read/write access to deploy changes made by developer Auditor – read-only access to specified systems Windows group policy security settings are used to lock down systems restricting access of to specific files/folders based on the role. Linux group policies and security scripts are deployed to multiple systems as well using the VAS interface through the AD management console Inbound access to systems from business partners and employees is via MetaFrame which uses role based access controls defined within AD & VAS group policies Access to the web interface utilizes Vintela’s Java based Single Sign On component which validates users and their access to confidential web pages Figure 5: RBAC in the DMZ 582816547 (05/25/17) Page 12 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 5 Securing the Internal Systems 5.1 Architecting the Internal Environment The internal systems will be comprised of a server VLAN and a user VLAN. The server VLAN will contain a Domain Controller, DNS, Email, Antivirus, File/Print, HR, and Web/App/Db servers. The majority of systems will be Windows 2003 and the role-based access control will be maintained through Windows Active Directory (AD). The Linux web and Solaris app servers will be managed by Vintela Authentication Services (VAS) as part of Active Directory. The Cisco IPS device will be a self-contained entity. The user VLAN will consist of desktop and laptop person-computers running Windows XP. These devices will be configured securely through Window Group Policy and role-based access controls will be granted via Windows AD. The roles associated with the personal computers will be administrator and business user. The business users (CEO, CFO, Sales Manager, Product Manager) will have read access to all files/folders but will have restricted write access to only specified non-system folders. They will also be prevented from installing software or modifying the registry. These tasks will require an administrator’s intervention. The developer role will be restricted to partitions on the web, app, and db servers. This will create a “sand-box” for development and testing. All production changes must go through a change management process, whereby the system administrator takes the developer’s changes and deploys them to production. These access controls will be a combination of Windows AD and VAS having file/folder permissions associated to them. The auditor will be provided temporary read access to designated areas of systems on a caseby-case basis. This role will remain disabled by default and only be enabled for specific audits. 582816547 (05/25/17) Page 13 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth RBAC for Internal Systems Access to the majority of GIAC Enterprise’s internal systems (Email, File, HR, Antivirus, DC, DNS) is governed by Windows Active Directory (AD) Access to the Linux/Apache web server and the Solaris/Weblogic App Server is controlled via Vintela Authentication Services (VAS) managed through AD Internally the following roles are defined: User - read-only access to web pages Administrator - read/write access to deploy changes to production after they’ve been made by a developer Developer – read/write access to development partitions of web/app/db servers Auditor – read-only access to specified systems Employees access the sales and HR database utilizing a web-to-app interface thereby abiding by a 3-tier architecture Systems are partitioned and segmented into development and production environments to facilitate configuration management practices Figure 6: RBAC for Internal Systems 582816547 (05/25/17) Page 14 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 6 RBAC for Network Devices 6.1 RBAC for Network Devices GIAC Enterprises will use Cisco’s Network Admission Control (NAC) to extend the concept of roles to the network devices. This will add another layer of defense-in-depth to the network. Devices attaching to the network will be examined and access may be granted depending on device patch status as well as user/device roles. Examples include: business users and guest users. Roles for the internal devices such as computers will be defined. For example, which devices get access to the internal wireless network and what systems or servers they can access from the internal wireless network. For non NAC compliant devices, NAC Profiler will be used to automatically identify and assess non-PC devices such as Voice over IP phones and printers. Using several sources of network information, NAC Profiler can identify devices, regardless of whether they are associated with a specific user. Workstations will have to meet minimum operating systems, critical applications, anti-virus, and anti-spyware patching requirements before access will be granted to even ‘ping’ the corporate systems. Devices that do not meet specific patch requirements can be patched via the policy server. If the device can not be updated, it will be corralled as a “guest” device and will be provided restricted network access to only the MetaFrame servers. NAC will be used to restrict and isolate vender devices and connections (i.e. visiting laptops). They will be restricted from the corporate network but still allowed Internet access. Roles can be defined via NAC or VLANs for Internet access, access to production servers, routers and other infrastructure devices. PGP’s encryption solution for computers, including laptops and desktops, secures the entire hard disk and therefore all the data on the computer. PGP interfaces with Active Directory so another user database would not be needed and the encryption process is transparent to the user. The user authentication process is synchronized with the Windows logon, so Windows users are automatically logged into their system without requiring additional authentication. PGP’s encryption can also be used to secure removable hard drives. If an encrypted computer is lost or stolen, the data on the device can not be accessed. Also note that encryptions keys are backed up and stored very securely to provide recoverability. In terms of physical security, Active Directory can be extended to access cards for the doors, labs, manufacturing and even the parking garage. They can also be used for two factor authentication (card: something you have + password: something you know) on card capable computers. Using cards tied to Active Directory credentials allows the logging of physical access as well as reducing costs in terms of replacing keys and adjusting employee’s access. 582816547 (05/25/17) Page 15 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth RBAC for Network Devices Cisco’s Network Admission Control (NAC) is used to control workstations and laptop access to the internal network IBNS and 802.1x is integrated into NAC (next slide) 802.1x provides controls for both wired and wireless devices NAC Profiler is used to automatically identify and assess non-PC devices such as Voice over IP phones and printers Appropriate device roles are created. For example, business user, guest user, etc... NAC is used to isolate vender connections (i.e. visiting laptops), while still allowing Internet access Ensure that authorized endpoint devices have been patched (operating systems, critical applications, anti-virus, anti-spyware, etc..) via the policy server. If the device is not up-to-date, it is quarantined and allowed access only to the remediation server If the device can not be updated, treat device as a “guest”, restrict access to only the MetaFrame servers. GIAC Enterprises uses PGP’s “Whole Disk Encryption” solution to secure data on laptops and at-risk desktops and removable storage. Figure 7: RBAC for Network Devices 582816547 (05/25/17) Page 16 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 7 RBAC for Infrastructure 7.1 RBAC for Infrastructure GIAC Enterprises will use Cisco’s AAA & TACACS+ via Cisco Secure Access Control Server & Active Directory for centralized router and firewall Authentication, Authorization, and Accounting. This will allow the network infrastructure to leverage Active Directory for user authorization. For auditing and trouble ticket resolution, Cisco’s Role-Based CLI Access can be used to define auditor and helpdesk views. These views can be configured to restrict access to Cisco IOS commands and configuration while allowing timely problem resolution and audit access to the IOS. Active Directory and Citrix MetaFrame can be leveraged to provide another layer of defensein-depth. Since the MetaFrame enabled applications can be accessed 24 hours a day/7 days a week, additional roles can be defined to provide users remote access to specific applications beyond normal work hours. Not only would user roles be classified to determine access to “what” system or application but also “when” they can access the application. RBAC for Infrastructure Use Cisco’s AAA & TACACS+ via Cisco Secure Access Control Server & Active Directory for centralized router and firewall Authentication, Authorization, and Accounting. Use Cisco's Identity-Based Networking Services (IBNS) identity management solution IBNS is based on 802.1x and offers authentication, access control, and user policies to secure the network 802.1X allows enforcement of port based network access control when devices attempt to access the network IBNS leverages Cisco's switches, Wireless APs, Cisco Secure ACS and Cisco Secure Services Client Cisco’s Role-Based CLI Access is used to define auditor and helpdesk views These views are configured to restrict access to Cisco IOS commands and configuration while allowing timely problem resolution and audit access to the IOS If SSH is needed, Quest OpenSSH provides password-less, secure, encrypted remote login and file transfer services for Vintela Authentication Services (VAS). The Cisco solution can also support VLANs and VPNs (if needed) Figure 8: RBAC for Infrastructure 582816547 (05/25/17) Page 17 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 8 RBAC for Separation of Duties 8.1 RBAC for Separation of Duties GIAC Enterprises can use RBAC as a deterrent for internal fraud by enforcing separation of duties. Fraud is a crime of opportunity; by enforcing separation of duties at an access level, the opportunity for fraud can be reduced. An example of this could be the separation of invoice payment approval and setting up a vendor in the accounting system. GIAC Enterprises can use the RBAC concept of static separation of duties to create roles that that will prevent a user from also having another role. For example, in terms of user administration, a person that authorizes new users or access will not be allowed to also have the role that allows them to establish a new user or access. In certain cases, dynamic separation of duties maybe necessary (limited number of users to do the jobs) but still retain some separation of duties. This would result in one user having both the “authorize” and “create new user” role but not be able to authorize and then create or grant rights to the same new user. RBAC for Separation of Duties GIAC Enterprises has developed roles to separate job duties User administration - The person authorizing the new user or access should not be the same one that establishes new user or access Accounting - The person approving the payment of an invoice should not be the same one that can create a company\vendor in the accounting system IT Administrator vs. IT auditor. While the auditor would need the same ‘read’ or access rights as an it administrator, they would not need ‘write’ or ‘modify’ rights The developer would require access to the development area but should not be allowed access to the production area Data Owner vs. Data Custodian, i.e. the IT administrator. In some cases, access to the data may need to be restricted to the data owner. IT would not be granted access, but would be required to ensure the security of it As mentioned, physical access can also be controlled via AD enabled key cards. This prevents access to unauthorized areas Figure 9: RBAC for Separation of Duties 582816547 (05/25/17) Page 18 Meyer & Ruppert, 2007 STI - Joint Written Project – RBAC Defense in Depth SANS Technology Institute 9 RBAC for Auditing 9.1 RBAC for Auditing GIAC Enterprises can benefit by defining audit roles in advance of the audits. The appropriate auditors can then be assigned those roles for the term of the audit. For ongoing auditing or compliance, the roles can be granted on a permanent basis. For example: internal IT department self-auditing or compliance vs. once-a-year audit. Properly implemented RBAC will make auditing user access that much easier. For example, instead of reviewing file and folder NTFS permissions on file servers, reports can be generated that list the roles each user has. Providing this report to the manager, he/she can quickly determine if that role is still appropriate for the employee. If access is no longer appropriate, the user is simply removed from the role and all of their access is terminated for that application or system. GIAC Enterprises can review the proper access rights for each role to ensure the role has the appropriate access to the system or application. RBAC for Auditing RBAC will ease auditing of network and systems Enforces unique usernames; only one username per user Define ‘read’ or ‘view’ only access to auditing roles Auditors can then be granted access to audit roles Appropriate event logs from servers, Active Directory, IPS, routers, Vintela Authentication Services, NAC, key card system and other network infrastructure devices are stored in a centralized log server Access to the centralized log server data is restricted, IT can not access, modify or delete logs without audit’s permission An event correlation and reporting server is used by both IT and audit to correlate and review the data Figure 10: RBAC for Auditing 582816547 (05/25/17) Page 19 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 10 Conclusion 10.1 Conclusion GIAC Enterprises inherits many security and administrative benefits from the implementation of RBAC but it may not be the holy grail of access control. This is especially true for organizations that have not or can not outline well-defined access roles. Care should be taken when implementing RBAC since it can be difficult and time consuming. The benefit to the organization should outweigh the Total Cost of Ownership3 (TCO). For some large organization, RBAC can be implemented at a high level. For example, a policy to standardize on unique user name for all systems, assigning rights to the roles or groups only and defining a set of roles that that are general rather then specific. “For large systems, with hundreds of roles, thousands of users and millions of permissions, managing roles, users, permissions and their interrelationships is a formidable task that can4 not realistically be centralized in a small team of security administrators.” It is also important to note that RBAC does not address user provisioning, the authorization for assigning users to roles or revoking those assignments. Additional policies and procedures will need to be developed. 3 Total cost of ownership (TCO) - is a financial estimate designed to help consumers and enterprise managers assess direct and indirect costs commonly related to software or hardware. Wikipedia 4 Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). "The NIST Model for Role Based Access Control: Toward a Unified Standard". 5th ACM Workshop Role-Based Access Control: 47-63 582816547 (05/25/17) Page 20 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth Conclusion GIAC Enterprises can benefit from Role Based Access Control by gaining scalability and efficiency By leveraging Active Directory and implementing the appropriate roles, GIAC Enterprises can increase security and reduce system administration costs While Role Based Access Control is considered a best practice at the system or application level, it becomes increasingly difficult to implement when scaling for large enterprises RBAC is not a product that can be implemented per se. Implementing RBAC involves careful planning for each systems and should involve users, management and policies for success Care should be taken when implementing RBAC in the Enterprise. If costs outweigh the benefits, RBAC implementation may need to be scaled back Figure 11: Conclusion 582816547 (05/25/17) Page 21 Meyer & Ruppert, 2007 SANS Technology Institute STI - Joint Written Project – RBAC Defense in Depth 11 References 11.1 References Vestergaard, Peter. Firewalls, Perimeter Protection, and VPNs Practical Assignment. http://www.giac.org/certified_professionals/practicals/GCFW/0309.php. April 2002 Gebel, Gerry. Roles and Access Management: Seeking a Balance Between Roles and Rules. Burton Group. June 2003 Peter Leight and Richard Hammer, Role-Based Access Control (RBAC) approach for Defense-in-Depth, August 2006 Nick Nikols, Gerry Gebel, Identity Lifecycle Management, Burton Group, Feb 2006 Wikipedia – Wikipedia.org Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). "The NIST Model for Role Based Access Control: Toward a Unified Standard". 5th ACM Workshop Role-Based Access Control: 47-63 582816547 (05/25/17) Page 22 Meyer & Ruppert, 2007