Information Technology | IT security » David Deighton - Architecture Guidelines, Application Security

Source: http://www.doksinet Architecture Guidelines – Application Security 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 Control the access granted to authenticated users based on a user profile. Credentials User name and password, or equivalents for systems (automated agents) EA Enterprise Architecture. Encryption Encoding of data so that it cannot be decoded (decrypted) without the corresponding key IAM Identity and Access Management IP Internet Protocol – a transport layer protocol within the TCP/IP stack IWA Integrated Windows Authentication – required setting in Internet Explorer 8/9. Kerberos Network authentication protocol RBAC Role Based Access Control SAML Security Assertion Markup Language SIB Standards Information Base containing standards and standard products SSO

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. TCP 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 Source: http://www.doksinet Architecture Guidelines – Application Security 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 Kerberos1 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 2 Kerberos is already used across the Windows / Unix divide in Business Intelligence. As defined in the Information Classification standard. Architecture Guidelines - Application Security / ISSUED / 08/11/2011 2/5 Source: http://www.doksinet Architecture Guidelines – Application Security Architecture Description The following diagram gives a high-level view of the proposed architectural approach. Kerberos3 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. Architecture Guidelines - Application Security / ISSUED / 08/11/2011 3/5 Source:

http://www.doksinet Architecture Guidelines – Application Security 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() Verify user credentials via security token or server credentials via certificate authenticate(user credentials) Single sign on (SSO) access request(user credentials) authenticate(TGT) ticket() access(HTTP) authenticate(TGT) ticket() CRUD(db credentials) authenticate(TGT) ticket() data/response() Get ticket once per session, not for every request data/response(HTTP) JDBC, ODBC etc. data(HTTP/S) 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 Focus on people and business practices    Security Policy and Standards Information Classification standard HR Processes including Joiners/Leavers etc. Application / Data Focus on applications and roles    Identity and Access Management (IAM) system Authentication, Authorisation, Encryption Role Based Access Control

(RBAC) Technology / Infrastructure Focus on infrastructure and physical security    Network topology, routing Firewalls Physical security Architecture Guidelines - Application Security / ISSUED / 08/11/2011 4/5 Source: http://www.doksinet Architecture Guidelines – Application Security Principles SEC1 Accountability All user and system interactions and access to information must be attributable to authenticated (reliably identified) people and systems. SEC2 Least Privilege When allowing access to a resource, assign the minimum necessary privileges to complete the job in hand. SEC3 SEC4 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 Implement a succession of barriers that an intruder must overcome before gaining access. A

combination of application and infrastructure security mechanisms are necessary to achieve good security. Guidelines: 1, 2, 3, 4, 5, 6, 7 Assume Insecure Communications Guidelines: 2, 5, 6 Defend in Depth Re-authentication will be required directly on the application or data server before access is granted. SEC5 No Security by Obscurity Security must be designed-in and not rely on hiding information. SEC6 Transparency Security mechanisms should not impair the ability of the University to function. 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 SAML Security Assertion Markup Language Kerberos or SAML tickets should be used as security 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). Architecture Guidelines - Application Security / ISSUED / 08/11/2011 5/5