Annex E: Application Security
Overview
The GC Enterprise IT/IS infrastructure exists solely to deliver application functionality to users. This in turn implies that the entire ESA exists to enable application security. Given this fact, it is important to define the scope of the Application Enterprise Security Focus Area (APP ESFA) and distinguish it from the other ESFAs that support it. This is illustrated by the iceberg metaphor in the image on the left. The part of the iceberg above the waterline represents mission-relevant capabilities delivered to GC workers, Canadian citizens, and Canadian businesses. The majority of users neither know nor care about the extensive underlying capabilities below the waterline that support the secure delivery of those mission-relevant capabilities to their desktops, laptops, and mobile devices. The tip of the iceberg represents the scope of the APP ESFA.
Application software is software designed to fulfill specific business needs derived from the mission and responsibilities assigned to the organization using the software. Application software does not include software such as operating systems, utilities, database management systems, web servers, etc. that exist to provide an available, reliable, and secure IT/IS environment for hosting application software. This supporting software is "below the waterline" and is not considered part of the APP ESFA.
At the heart of the APP ESFA is an analysis of the security considerations associated with different application software architecture models. These are primarily the information access model (client-server, service-oriented, etc.) and the real-time interactive communication model (voice, video, chat, unified communications, etc.). The other ESFAs provide supporting security capabilities that are leveraged by the application architecture models to deliver secure application functionality to users. The relationships between the APP ESFA and the supporting ESFAs are key elements of an overall application security architecture.
Application development, acquisition, and deployment share many characteristics with software development, acquisition, and deployment in general. These are primarily processes supported by technology and are ideally addressed in the Security in Acquisition (ACQ) ESFA. Security Operations (OPS) ESFA capabilities also play a significant role in tracking software assets (Asset Management), tracking versions of software installed on endpoints (Configuration Management), and managing installation of software updates. Compute and Storage Services Security (CSS) ESFA capabilities provide the data centre/cloud provider capabilities that perform dynamic resource management to ensure that running applications meet availability and performance requirements. Endpoint Security (END) ESFA components provide the hardware platforms and operating environments (e.g. operating system, hypervisor) that host application functionality.
A unique feature of application software versus other types of software is the concept of self-service: users can selectively install the applications necessary to perform their job functions. Providing self-service application installation is the function of the Application Store component. While "App Stores" are typically associated with smartphones and tablets, the concept is equally applicable to desktops, laptops, and other types of endpoint devices. When an application is installed by the user from an App Store, the installation must be reported to OPS ESFA capabilities such that the status of the application can be monitored and any reported vulnerabilities remediated.
For information about a subset of architectural needs that are related to the APP ESFA, please read the ESADD Annex E: Application Security (APP) document.
Components
The image below identifies the APP ESFA technical components and ACQ ESFA non-technical components that ensure secure development, acquisition, and deployment of application software. The non-technical components are applicable to software development, acquisition, and deployment in general. For a table describing the APP and ACQ components, please refer to the ESADD Annex E: Application Security (APP) document.
Context
The image below shows the context of APP within the architecture of the GC Enterprise. The APP ESFA interacts with most of the ESFAs as well as several of the external entities. For a full list and description of GC enterprise actors, please read the GC ESA ConOps Main Body.
For a list of APP interfaces and a more detailed description of each one of them, please read the ESADD Annex E: Application Security (APP) document. These interfaces are depicted in the image below. This layered view shows the subset of components that are visible to, and must be considered by, application developers.
Perspectives
This section provides context and additional information to support the target architectural views found in the ESADD Annex E: Application Security (APP) document.
This section also discusses key capabilities relevant to application security that are not within the scope of the Application Security ESFA. In particular, the Compute and Storage Security (CSS) ESFA provides capabilities that support secure execution of applications in data centres and clouds.
These capabilities access and manage the underlying trusted execution environments provided by server platforms. The same trusted execution environment capabilities are available on end user devices and are provided by the Endpoint (END) ESFA.
The following subsections, which can be expanded by clicking on 'Expand' on the far right, provide contextual information that should be considered for improving application security.
Actors, Roles and Responsibilities
The image on the right shows the roles that interact with a server-hosted enterprise application:
- The Platform Administrator is responsible for the server platform, which includes the hardware and installed software. The Platform Administrator installs, updates, and patches installed application software but does not interact with running application software. To support separation of duties, a Security Operator (not shown) may be authorized to perform certain security-critical functions that are not available to the Platform Administrator.
- Application, Database, and Middleware Administrators interacts with running software processes to perform privileged functions. This may include configuration of account and privileged information that is maintained independenetly of operating system authentication and authorization mechanisms.
- System Administrator is a generic role that encompasses all of the administrative roles described above.
The Application, Middleware, and Database Administrators typically administer services from a remote client, particularly if the servers hosting the services reside in a "lights out" data centre or offsite cloud environment. The client may be specific to the application or it may be a generic client such as a web browser. End Users may use the same or a different client to access an application service. The service, not the client, determines what capabilities are authorized based on the authenticated user's configured privileges.
Use of a separate network interface connected to a management network is preferred for managing server platforms and hosted services. Isolating privileged administrative interfaces from the relatively insecure production network reduces the risk of any vulnerabilities in the administrative interfaces from being exploited by an attacker. Administrators should also use a dedicated administrative workstation or a workstation that logically separates administrative and production environments using, for example, virtual machine technology. For more information, please read the ESA ConOps Annex D: Secure Enterprise Systems Administration document.
The Platform Administrator has the necessary operating system administrative privileges to update software images and configuration files that are not writable by other roles. Running processes may have read/write access to selected configuration files, which makes them indirectly accessible to Applications Administrators, Middleware Administrators, or Database Administrators. These files are likely also accessible to the Platform Administrator but, depending on their formats, the Platform Administrator may not have the necessary tools to update them. A configuration file or database maintained by an application service could include, for example, the list of usernames, credentials, and privileges of users authorized to log in to the application (authenticated by the application service rather than by the operating system).
The Platform Administrator is generally the only role able to manage workstations (client endpoints), although an authorized End User may have limited privileges to install software (particularly scripts and other interpreted code) and perform client application configuration functions.
For client and server endpoints, Platform Administrator management functions, such as updating software, may be automated using management servers. These automated servers must possess the necessary authentication secrets to be granted the required privileges.
A physical person may serve in more than one role. In particular, a person acting in the role of an Application, Database, or Middleware Administrator may also act as a Platform Administrator for the purpose of installing and configuring the software on the host platform.
If users sharing the same role are from different organizations, it is important that the responsibilities of each user be clearly defined. Audit logs should be regularly examined to determine whether any users are exceeding their defined responsibilities.
For more information, please read the ESADD Annex E: Application Security (APP) document.
Application Security (APP) Target Security Architecture
The target security architecture describes the capabilities provided by ESA components to support secure interoperability among application services. These capabilities and the relationships among components provide the basis for the patterns and use cases described in section 5 of the ESADD Annex E: Application Security (APP) document. While the target architecture may never be fully realized, it provides a vision for the transition architectures described in section 4 of the ESADD Annex E: Application Security (APP) document.
The architecture consists of several views:
- The Information Access Application Service Architecture view describes a modular, loosely coupled service-oriented approach to information access based on the concept of microservices.
- The Interactive Communications Application Services Architecture view provides a brief discussion on securing Unified Communications and Collaboration (UC&C) solutions. Whereas application services are often custom-developed to meet specific needs, UC&C solutions are generally assembled from commodity COTS products. Accordingly, the choice of specific architectures may be limited.
- The Identification, Authentication, and Authorization Architecture view describes how enterprise applications interact with centralized authentication and authorization services.
- The Client Access Architecture view summarizes the different ways in which client devices (workstations, laptops, tablets, etc.) access local and remote application services.
The ESA ConOps Annex C: Secure Enterprise Application Delivery document provides detailed information on deployment of a Service-Oriented Architecture (SOA) based on web services protocols within the GC. This annex takes a more abstract view of a service-oriented architecture and provides the Application Architecture Models. Different application architecture models present different security concerns. The two main application architecture models are illustrated in the image on the right:
- Information Access Services Model: Traditional applications that allow creation, reading, updating, and deletion ("CRUD") of shared data subject to access control policy. These applications do not typically operate in real-time or near real-time, but may support delivery of streaming non-interactive media. The model is represented by the Information Access Application Service component.
- Interactive Communications Services Model: Applications primarily mediate real-time and near real-time communications among human users. Includes capabilities such as instant messaging/chat, interactive voice and video, whiteboarding, video conferencing, etc. This model is represented by the Interactive Communications Application Services component.
Many modern applications exhibit characteristics of multiple models. For example, information access applications may act as proxies for human users and use unified communications application capabilities to send notifications.
Each application model supports multiple paradigms. For example, information access applications can be client-server, three-tier, service-oriented, etc. Interactive communications applications may have different characteristics for different types of real-time media. New forms and combinations of interactive communication will evolve over time.
In both models, the Information Access Applications component and the Interactive Communications Application component may be supported by the Application Interoperability Services component that provides high-level application interoperability services (middleware) layered on top of underlying networking and communication services provided by components from the NCS ESFA.
Information Access Application Services Architecture
The decomposition of applications into discrete services began with Service Oriented Architecture (SOA). Often based on legacy monolithic applications, a SOA-based service typically contains a large amount of tightly coupled code with complex dependencies. The size and complexity requires extensive planning, development, and testing to add and deploy new features. This is counter to the concept of agility. Future application environments will embrace two views of agility. The first is the ability to rapidly develop and deploy new and updated application functions to meet user expectations. Instead of introducing new and updated functionality once or twice a year, many organizations that embrace the DevOps concept are able to do so every few days, or several times per day. For DevOps to be effective, code must be decomposed into small, loosely coupled services, each of which can be developed and maintained by a small, tight-knit group of developers who have a thorough understanding of the code.
The emerging architectural concept to meet this need is the concept of "microservices". In brief, a system based on the Microservices Architecture (MSA) pattern should be comprised of a set of microservices, each of which has a single responsibility that it should perform really well. Not all microservices are necessarily small - trying to decompose a service in which the code is both tightly coupled and highly cohesive will do more harm than good - but they each should have a well-defined purpose. To ensure that microservices are as loosely coupled as possible, microservices should not share files or databases - all sharing of information is via network interfaces. For example, a single microservice may be responsible for a database and receives requests to create, read, update, or delete ("CRUD") data in the database via service requests over the network.
In fact, the traditional concept of an "application" may no longer be applicable in an enterprise environment. Instead, microservices may be mixed and matched as needed to meet an organization's specific operational and business requirements. A high-level view of the microservice architecture is shown in the image on the left.
Fundamentally, MSA is SOA using finer-grained services (microservice vs. services) and lighter-weight communication mechanisms (REST vs. WS-*). It is not true that "SOA = Web Services". The fundamental problem of how to compose and coordinate a set of microservices to provide a seamless experience to the end user remains. In an MSA, the orchestrator may be just another microservice rather than being a middleware element (such as an orchestrator in an ESB).
There is a current trend away from orchestration of business processes towards a choreography approach ("smart endpoints and dumb pipes"), but this is not universal. Centralized orchestration can introduce bottlenecks, and the idea of centralized control does not play well in cloud environments, especially hybrid clouds where internal services may be interoperating with external cloud-based services. The downside of choreography is that it introduces complexity in that services need to understand their roles in various business processes.
With orchestration, a single orchestrator "conducts" the microservices, telling them what to do and when. Each microservice responds to requests in a synchronous manner and has not knowledge of the larger business process in which it is participating. With choreography, microservices are aware of the business processes of which they are a part. In an event-driven choreography scheme, when a microservice completes a step in a business process, it posts an asynchronous event.
At that point, the next mecroservice in the business process detects the event, performs its step, and posts another event. Both orchestration and choreography allow steps to be performed in parallel. A decentralized asynchronous approach generally provides looser coupling (which better supports small independent DevOps teams) but has poor or no support for transactions. If a transaction cannot be completed for any reason, the microservices must coordinate with each other to identify and resolve any inconsistencies rather than relying on a centralized, synchronous orchestrator to implement a two-phase commit (2PC) protocol. The end user may also be actively involved in ensuring the consistency and integrity of all services and their associated databases. In practice, an MSA-based system is likely to use a combination of choreography and orchestration with one or more microservices performing orchestration functions (i.e. there is no dedicated orchestrator typically present in a traditional SOA).
As a relatively new concept, there is no single formal definition of a microservice, but industry consensus is that microservices should be stateless and not share access to persistent data stores. Any required state information is exchanged over the network via APIs, and any access to a shared data store should also be via an API call to the microservice responsible for the data stored.
In a traditional SOA based on the Simple Object Access Protocol (SOAP), cryptographic confidentiality and integrity protections are applied to individual SOAP messages. THis enables SOAP messages to be carried by a range of transport protocols as they are not required to (but may) provide any security protections. These are often connectionless messaging protocols. EST, on the other hand, is based on the HTTP protocol and is therefore limited to TLS for provision of cryptographic protection services. This hinders the provision of end-to-end security mechanisms, although REST parameters could be cryptographically protected (e.g. digitally signed) and encoded in test form. REST parameters are normally encoded using JavaScript Object Notation (JSON). Being REST-based, microservices tend to use different authentication protocols. Whereas SOA-based applications tend to use SAML for forwarding authentication information, microservices tend to use JSON Web Token (JWT or "jots). If the GC transitions towards a microservices architecture, it will be critical that the roadmap for GC ICAM is aligned. The overall trend is away from XML towards JSON.
As REST is based in HTTP, the user interface can be handled entirely by the API Gateway, the API Gateway may compose hypertext elements received from individual microservices, or a specific microservice may be dedicated to handling the user interface. There is no industry consensus at present and the best approach is likely to depend on the nature of the application.
The proliferation of small services that result from a microservices architecture results in a number of security challenges that must be addressed. These challenges are not fundamentally different from those encountered with a traditional SOA but, as microservices increase the attack surface, any vulnerabilities in the security solution are likely to be amplified. In monolithic and service-oriented architectures, communication among software components is mostly internal. With a microservices architecture, much of this communication is now external using a multitude of potentially vulnerable APIs. Additionally, a microservices deployment is likely to rely on a wider range of operating systems and programming languages, each with its unique set of security vulnerabilities. A final problem is that microservices result in a lot of network traffic and may result in poor response times due to bandwidth constraints and increased latency.
The upside of a microservice approach is that security updates to microservices can be deployed more rapidly than can occur for monolithic services with complex code dependencies. The latter generally need regressive extensive testing prior to being deployed. As release cycles for services are counted in months, rather than days or weeks for microservices, vulnerabilities can remain in the production environment for considerable periods of time. Being small and highly cohesive, microservices are easier to evaluate from a security perspective than monolithic services.
The microservice concept and associated protocols will evolve or be replaced over time, but the overriding architectural concept of an application service doing one thing and doing it very well will persist.
Interactive Communications Application Services Architecture
The target architecture for Interactive Communications Application Services is Unified Communications and Collaboration (UC&C) that seamlessly integrates a number of communication services:
- IP-based voice and video communications (one-to-one and many-to-many) conferencing
- Instant messaging
- Presence
- Desktop, monitor and window sharing
- Interactive whiteboards
- Mobility (single number for multiple devices)
- Integration with Unified Messaging capabilities (email, voicemail, SMS, etc.)
The security concerns with UC&C data services (i.e. other than interactive voice and video) are essentially same as those for Information Access Application services. Solutions include the implementation of Identification, Authentication and Authorization (IA&A) capabilities together with the use of cryptographic techniques protect the confidentiality and integrity of data.
Voice and video have some unique characteristics that result in security concerns not faced by UC&C data services:
- Identification, Authentication, and Authorization may be performed manually by users. While it is becoming more common for users to rely on devices capable of using the same IA&A mechanisms and tokens used for data (desktop and laptop computers, tablets, smartphones), many users will continue to connect using VoIP desk phone or from the PSTN indirectly through a VoIP gateway. Caller ID provides a hint as to who is calling, but ultimately authentication is based on voice and conversational characteristics.
- Interactive voice and video protocols are true real-time protocols where traffic delays and lost packets will disrupt communications (cause voice and video breakup) if they exceed relatively small thresholds. This requires implementation of Quality of Service (QoS) capabilities when voice and video traffic share the same physical cables as data traffic.
Other things to discuss:
- Conferencing Servers
- RFC 4353 - A Framework for Conferencing with the Session Initiation Protocol (SIP)
- Loosely Coupled Conference - Uses multicast, no signalling
- Fully Distributed Multiparty Conference - Uses multicast, signalling relationships with other participants
- Tightly Coupled Conference - Connect to the conference server
- Conferencing servers can also provide collaboration services
- RFC 4353 - A Framework for Conferencing with the Session Initiation Protocol (SIP)
- Session border controllers (SBCs) relay VoIP and SIP traffic between different domains/zones. They are usually found at the public interface to a commercial VoIP service provider. They may be co-located with media gateways that convert between different voice or video encoding formats (transcoding). SBCs may also provide lawful interception of calls and provide protection against Denial of Service (DoS) attacks.
Communications Security
Point-to-point VoIP sessions may be secured using the Secure Real-Time Protocol (SRTP), which provides confidentiality, integrity, and replay protection.
The Session Initiation Protocol (SIP) is the most common protocol for initiating and accepting VoIP calls. It is also frequently used for instant messaging, multimedia conferencing, and presence detection. Correct configuration of SIP agents and servers is therefore an important aspect of securing UC&C capabilities.
SIP is an "out-of-band" protocol in that it uses a different communications session to that used by the interactive communication session itself. The participants in a communication session may be registered with the same SIP server, or they may be registered with different SIP servers. Transport Layer Security (TLS) is often used with SIP to provide confidentiality and integrity protection of SIP messages.
If the interactive communication session is to be encrypted or cryptographic integrity protection applied, mutual authentication may be performed in-band (via the real-time communications channel) using the Z Real Time Protocol (ZRTP) or out-of-band (via the SIP channel) using the Multimedia Internet Keying (MIKEY) protocol.
Quality of Service
Real-time interactive voice and video is sensitive to latency, packet loss, and jitter. When voice or video is sharing physical resources (cables, switches, etc.) with other types of data, it must be given priority over non-real-time traffic. Techniques for providing QoS:
- Over-Provisioning: If the network is sufficiently over-provisioned, there will be no competition for network resources.
- Integrated Services: Applications use a protocol (such as the Resource Reservation Protocol) to request and reserve resources through a network.
- Differentiated Services: Each packet is marked with a service type that is used by switches and routers to prioritize the packet.
Identification, Authentication, and Authorization Architecture
As application services become more fine-grained and numerous, it becomes impractical for each application service to individually authenticate the attributes associated with the requesting user. The target application architecture therefore relies on a centralized authority (identity provider) that attests to the validity of the attributes associated with the requesting user.
The image below shows a high-level view of enterprise identity authentication in which the end user authenticates his enterprise identity once and forwards an identity assertion to one or more enterprise applications. Prior to contacting an application service, the workstation must obtain an authenticated set of user attributes that it can forward with the application request. The ICA Services component authenticates the identity of the user by providing a user ID that only the legitimate owner of the user ID knows.
If the knowledge of the secret value is proven, the ICA Services component returns a digitally signed assertion that contains the user's attributes. The workstation forwards the assertion to the requested application service. The application service verifies the digital signature on the assertion and, because it trusts the signer, uses the attributes to make an authorization decision. An assertion may be encoded using the Security Assertion Markup Language (SAML) or a newer lighter-weight protocol, such as JSON Web Token (JWT) that uses JSON rather than XML. Note that JWT uses the term "claim" in place of "assertion".
A single identity assertion can be used with multiple application services, or the identity provider can issue different identity assertions for different application services over a single authenticated session. This provides a single sign-on (SSO) capability that enables an efficient and seamless user experience in combination with an orchestrated or choreographed set of application services. If different application services require different levels of authentication assurance, an integrated architecture can provide "step-up" authentication when needed with minimal impact on the user's experience.
The image above shows an application service invoking subordinate application services to provide the requested service to the end user. This requires identity delegation in which the requesting service notifies the requested service that it is "acting as" or "acting on behalf of" an identified end user (also known as "principal propagation"). The image shows the end user's enterprise identity assertion being forwarded by the requesting service to the requested service (over a mutually authenticated session), but there are other methods by which the identity of the original requestor can be asserted. Intermediate application services must be trusted to correct, verify and forward the asserted identity.
A centralized identity provider relives each application service from having to implement its own authentication mechanisms, but it is still necessary for the application service to make an authorization decision based on the asserted identity attributes. As services become smaller and finer grained, they do not necessarily have the context required to make a decision. This motivates the need to centralize authorization decisions in addition to authentication decisions.
For more information about enterprise identification, authentication, and authorization, please read the GC Enterprise Identity Management Strategy.
Application Client Services
This section discusses different ways in which end users can gain access to application functionality from a client endpoint:
Generic Client
A "clientless" approach generally refers to the ability to access application functionality via client software that is not application-specific. The most common type of "clientless" client is the web browser. The ability to download scripts and applets enables the creation of sophisticated user interfaces. As code is dynamically downloaded, it also reduces the maintenance effort in that software updates need to be applied to a relatively small number of server endpoints rather than a large number of client endpoints. This has become the preferred access architecture for enterprise application services.
Application-Specific Client
An application-specific software package is installed on the client device. This is the most common approach for standalone (not server-based) software packages, such as an office suite, but there is a trend toward cloud-based approaches in which application functionality is relocated from the client endpoint to server endpoints (e.g. Microsoft Office 365) to create a clientless approach. However, custom client applications may still be required to enable offline working. Custom clients may also be required to support server-based applications, but the trend is also towards a clientless approach. The primary problem with a custom client approach is the need to update a large number of client endpoints when the custom client software is updated. Not only does this increase maintenance costs, but out-of-date software can result in the presence of vulnerabilities and increase the risk to the GC. A final consideration is that of cost in that custom client software may be licensed based on the number of installations and not on concurrent usage.
An application-specific client may be installed remotely using OPS ESFA capabilities, or the end user may self-install the client from an application store. In both cases, the client endpoint should verify a digital signature over the application-specific client to ensure its authenticity. The client endpoint may also be configured with an application blacklist or whitelist that limits which applications can be installed.
Virtualized Client
Application virtualization can be considered a variant of the clientless approach in that application-specific software is not installed on the client endpoint. Application virtualization can enable clientless use of application-specific clients. The application-specific client software may be executed on a server and accessed using a remote desktop client, or it may be dynamically streamed to the remote desktop client as needed.
ESADD Annex E: Application Security (APP) Pattern Diagrams
For the Pattern Diagrams for Network and Communications Security (NCS) from the ESADD Annex E: Application Security (APP) document, please visit the ESA Pattern Diagram Repository.
List of ESADD Annex E Pattern Diagrams
- Pattern PN-END-001 Identification, Authentication, and Authorization (IA&A)
References
- ESADD Annex E: Application Security (APP)
- ESA Description Document Main Body
- ESADD Annex C: Network and Communication Security (NCS)
- ESADD Annex D: Security Operations (OPS)
- ESADD Annex F: Compute and Storage Services Security (CSS) DRAFT
- ESA ConOps Annex B: Cloud Security
- ESA ConOps Annex C: Secure Enterprise Application Delivery
- ESA ConOps Annex D: Secure Enterprise Systems Administration
- END ESFA
- OPS ESFA
- CSS ESFA
- ESA Pattern Diagram Repository
- Enterprise Identity Management Strategy
- ITSG-33 IT Security Risk Management: A Lifecycle Approach
- FIPS 140-2: Security Requirements for Cryptographic Modules
- DevOpsSec: Delivering Secure Software Through Continuous Delivery
- SAFECode Fundamental Practices for Secure Software Development
- OWASP AppSensor Guide
_Context_View.PNG){kind=link}
.PNG){kind=link}
