Executive Summary These guidelines describe best practice for application security for 2 or 3 tier web-based applications. It covers the use of common security mechanisms including Authentication, Authorisation and Encryption. All users (or systems) requiring access should be authenticated before they actually reach the target application using single sign-on (SSO) based on the Windows login where users are checked against Active Directory. All servers involved in a transaction, or use case, must perform authentication of the user credentials by means of an encrypted security token such as a Kerberos ticket issued by Active Directory. Network security mechanisms cannot be relied upon because they do not deal with the specific rights of individual users, therefore application-level security is necessary. User credentials such as passwords must never be transmitted in clear across the network but must always be encrypted. Single sign-on is based on Windows authentication with Active Directory and Unix-based applications may participate in SSO via plug-in components that interact with Active Directory. Definitions Authentication Identification of users and automated agents that attempt access. Authorisation Credentials EA Encryption IAM IP Control the access granted to authenticated users based on a user profile. User name and password, or equivalents for systems (automated agents) Enterprise Architecture. Encoding of data so that it cannot be decoded (decrypted) without the corresponding key Identity and Access Management Internet Protocol a transport layer protocol within the TCP/IP stack IWA Integrated Windows Authentication required setting in Internet Explorer 8/9. Kerberos RBAC SAML SIB SSO TCP Network authentication protocol Role Based Access Control Security Assertion Markup Language Standards Information Base containing standards and standard products Single sign-on users sign on once only and their credentials are propagated so that server-based applications can authenticate using an encrypted security token. Transmission Control Protocol part of the TCP/IP stack. Purpose The guidelines apply to business applications that are deployed in campus datacenters and accessible via the campus network. They provide a rules, or recommendations, that promote good security in line with industry best practice. This document is intended to help focus on the security architecture of an application early in its life cycle so that the security can be designed in from the start. Architecture Guidelines - Application Security / ISSUED version 1.0 / 08/11/2011 David Deighton, IT Architect 1 / 5
Guidelines 1 Authenticate users before they reach the application. Users should be positively and reliably identified at the point of access to the network and authenticated against Active Directory. 2 Authenticate access to all servers Each server that participates in a transaction, or use case, has the responsibility to verify the legitimacy of access requests. This does not mean forcing users to sign-on multiple times; it can be achieved through exchange of security tokens such as Kerberos 1 or SAML tickets. Web servers are generally exempt since they should not be used to hold sensitive information. 3 Encrypt highly confidential data. Data that is classified Highly Confidential 2 (or above) must be encrypted both at rest and in transit as defined in the Information Classification standard. 4 Base security on user credentials. Ultimately what counts is the level of access granted to specific users (whether people or automated agents) to specific information. The application security should be complete, internally consistent and not unduly reliant on network security. 5 Do not rely exclusively on network security Network security mechanisms based on routing, firewalls and server security based on exchange of certificates or control of IP addresses can help reinforce security but do not address the central issue and are therefore insufficient by themselves. 6 Promote Separation of Concerns User interface, presentation, business logic and data storage should be separated in a tiered architecture for improved security as well as scalability, performance and resilience. 7 Encrypt credentials User passwords must never be transmitted in clear text, even within a highly secure network zone. Ideally, passwords should never be transmitted or stored anywhere outside the security system itself. 8 Adopt Role Based Access Control (RBAC) Assign access privileges to roles, implemented as groups in Active Directory, rather than individuals. This should simplify administration and decouple individuals from applications. Access control is normally the responsibility of applications because it requires knowledge about application structure which is usually not available centrally. 1 Kerberos is already used across the Windows / Unix divide in Business Intelligence. 2 As defined in the Information Classification standard. 2 / 5
Architecture Description The following diagram gives a high-level view of the proposed architectural approach. Kerberos 3 is the network authentication standard shown, but SAML is equally secure. Figure 1 Deployment View The diagram shows Kerberos tickets emitted by Active Directory being used for authentication on Unix and Windows based servers. Kerberos is preferred since it is already live at the University. 3 Note that Kerberos requires Integrated Windows Authentication (IWA) to be enabled in the web browser. 3 / 5
Applications may also directly query Active Directory using LDAP where no plug-in component is available for the purpose of user authentication and to import organization units and groups for use in internal access control. The web servers are excluded from the authentication requirement since they should not be used to hold confidential information. But where web servers are embedded into the application then they should be subject to the same constraints as the application servers. The following diagram shows a scenario where all steps succeed. Active Directory is the Kerberos ticket server and responds to all requests by issuing a ticket. In practice, it would not be necessary to request a ticket for every transaction but only once per session if there is a mechanism for storing (caching) the ticket between requests. sd Security Client PC Active Directory Web Server Application Server Database Server User sign on() authenticate(user credentials) Verify user credentials via security token or server credentials via certificate Single sign on (SSO) access request(user credentials) access(http) CRUD(db credentials) data/response() Get ticket once per session, not for every request data/response(http) data(http/s) JDBC, ODBC etc. response() Figure 2 Authentication Sequence Diagram Security requires a layered approach in which the business and application layers are underpinned by a range of technical and physical security mechanisms. Business / Information Application / Data Technology / Infrastructure Focus on people and business practices Focus on applications and roles Focus on infrastructure and physical security Security Policy and Standards Information Classification standard HR Processes including Joiners/Leavers etc. Identity and Access Management (IAM) system Authentication, Authorisation, Encryption Role Based Access Control (RBAC) Network topology, routing Firewalls Physical security 4 / 5
Principles SEC1 SEC2 SEC3 SEC4 SEC5 SEC6 Accountability All user and system interactions and access to information must be attributable to authenticated (reliably identified) people and systems. Least Privilege When allowing access to a resource, assign the minimum necessary privileges to complete the job in hand. Defend in Depth Implement a succession of barriers that an intruder must overcome before gaining access. Assume Insecure Communications Re-authentication will be required directly on the application or data server before access is granted. No Security by Obscurity Security must be designed-in and not rely on hiding information. Transparency Security mechanisms should not impair the ability of the University to function. User credentials should be propagated all the way through an application and included in all audit logs even if service accounts are used to access databases etc. Guideline: 4 Avoid superuser accounts, access control should be specific and fit the business need. Guideline: 4 A combination of application and infrastructure security mechanisms are necessary to achieve good security. Guidelines: 1, 2, 3, 4, 5, 6, 7 Guidelines: 2, 5, 6 Security should not be compromised by the availability of design documents such as network diagrams. Guideline: 5 Security tokens such as Kerberos or SAML tickets, should be used to avoid onerous multiple sign-on. Guideline: 2 Standards Applicable standards include: AES Advanced Encryption Standard The AES algorithm should be used for all encryption needs, preferably with 256-bit keys. HTTPS Hypertext Transfer Protocol Secure Protects web traffic by encrypting with an implementation of the AES algorithm (TLS/SSL). Kerberos Network Authentication Protocol Kerberos or SAML tickets should be used as security SAML Security Assertion Markup Language tokens involved in server authentication. Further Information If you have any questions or comments concerning this document, please contact IT Architecture via email. Security and other architectural principles can be found in the Enterprise Architecture Principles document. Standards can be found in the IT Services Standards Information Base (SIB). 5 / 5