Security at Cloud Expo

Cloud Computing Expo - Modern inter-networked software architecture created for today's "on-demand" business needs have fundamentally increased the susceptibility of applications and, more important, data to security-related attacks and compromises.

The rapidly changing environment: increased data breach/loss incidents, increased number of regulations and compliance requirements, potential liability/litigation concerns and erosion of reputation and public confidence provides ample drivers for development teams to have a security mindset.

No longer should application architects and administrators simply be content with perimeter/border controls such as firewall, IDS and other static defenses. Instead, a more holistic perspective needs to be taken in the approach towards application security - throughout the entire software development lifecycle, encompassing concept and planning through operations and ultimate disposal.

Presented is a case study of a JEE system developed addressing some of these application security concerns.

Introduction
The organization, a State Government agency, needed a reliable way to to deliver applications to internal customers, improve data accuracy, build integration linkages to other internal enterprise systems and offer "self-service" web access. The core project requirement was to fully consolidate back-office functions into a single business process management suite: the Comprehensive Retirement Intranet System (CRIS). The scope of the solution needed to cover all use cases related to business process workflows, scenarios, transactional definitions and record maintenance pertaining to centralized online processing and administration of retirement payroll deductions, payments and claims functionality. The system, broadly, had to track benefits, and calculate and electronically disburse payments for the multi-billion dollar pension systems supporting the state's hundred of thousands of covered employees, teachers, police officers, general assembly members, judges, solicitors and National Guard. The system also had to support various internal and external reporting needs mainly for customers, auditors, the IRS and state/federal regulatory compliance and had to be amenable to rapidly deployable modifications due to legislative/law changes.

Figure 1 shows the different functional "business process" areas covered within the system. The dotted boxes represent individual web modules (I'll discuss this in a later section) developed to encapsulate the specific business processing functionality while the solid green boxes represent external systems that the system needed to be integrated with [1] and [2].

The development was done in-house, so as to control quality and speed the applications development and testing turn around time, with a project team comprising of about 12 developers, two QA staff members and one project manager. Security was an integral part of our SDLC process, therefore, rather than talk about security as a standalone part of the architecture, I'm going to show how it was integrated into the design/development process.

The Development Methodology
In planning the development methodology approach (which eventually ended up as a mix of Spiral, JAD and Agile) we looked at the following attributes:

• Strong emphasis on initial prototyping, progressively elaborating technical design (architectural, procedural, data), testing life-cycle (unit, integration, system, acceptance) and effective configuration management.
• Places where development controls (such as peer code reviews) and change controls (configuration management) can be slotted in
• Works for the organization's size and process maturity
• Has the potential for reduction of programming error rates and improves developer productivity

The following are the development phases along with some of the security-related issues that were addressed at each phase.

Functional Design - defining asset classification, confidentiality and integrity of data being accessed or updated; authentication/authorization requirements; encryption requirement (PKI); business rules checks/validation to prevent data corruption; interface requirements to other "open standard" systems; fraud and audit controls (e.g., all transactions above preset limits be automatically queued for administrative review by functional area supervisors); user and events logging requirements.

Software Design - software components n-tiered architectural model with defense in depth built into the tiers; informational model addressing structural/procedural design with abstraction and obfuscation between layers; design of role-based access control matrix for application users using principle of least priviledge; leverage widely accepted and tested frameworks/toolkits and avoidance of complex blackboxed architectures.

Software Development/Implementation - implementation of programming best practices; exception handling in a fail secure manner; debugging and peer code reviews to identify common coding flaws; avoidance of tricky or clever code over simplicity and adequate code documentation for ease of maintainability, proper configuration/versioning and change control management to prevent code corruption; evaluation of performance and penetration resistance; testing of pages and interfaces with improperly formatted and unexpected inputs; DoS tests on resource intensive processes; testing in different environments under various loads and secure network topology of the distributed system components.

Software Testing - Unit testing of individual components in the controlled/development environment to validate data structure logic and boundary conditions; integration testing by verifying that components work together as outlined in design specifications; acceptance testing to ensure that system meets customer requirements; regression testing to ensure functionality performance and protection after significant changes to the system.

Software Design
EntireX as the Communications Middleware
Since the organization had already invested in the Natural/Adabas development platform (from SoftwareAG), in terms of tooling, infrastructure and developer expertise, all business and procedural logic for fulfillment of the system functionality was written in the Natural programming language with the help of Natural Construct, a set of development tools that automatically generates Natural modules. The integration tool EntireX was used to open up the Natural applications for online presentation to a Java web component, which is able to provide certain functions as a Web service for internal 'smart client' applications [1].

EntireX Broker is a middleware technology developed by SoftwareAG [4] that we adapted to essentially control communication among the distributed application components within our internal IT landscape. EntireX Broker is particularly well suited for integration involving legacy systems and other packaged ERP software, and works extremely well in an environment that is a host to other SoftwareAG products such as Adabas and Natural. It essentially acts like a switchboard in that it accepts messages from client stub components; forwards them after authentication to the requested server component via Remote Procedure Calls (RPC), a synchronous process where one program requests (calls) the services of another program located on a different machine; and relays the response back to the client.

The EntireX Communicator is an integration server composed essentially of three core infrastructure components: the EntireX Broker Kernel; Wrappers, which package parameter/result arrays of message types for serialization into the Remote Procedure Call; and the Workbench tool, for stub and proxy development. An application business function (such as fulfillment of a direct deposit EFT payment developed in Natural, for example) is added to the EntireX Communicator as a non-XML aware RPC service, and, once added, it can be integrated into the application simply by generating a new proxy class (also called "Generated" class) in Java. This process requires little coding and can be performed through the use of wizards and templates to make the process developer friendly. At runtime, the application calls the proxy class that builds the necessary message structures and sends the message to the Natural program routed via the Broker Kernel. EntireX Communicator works with any development environment and has specific bindings for COM, ActiveX, Java, and CORBA. Communications can be asynchronous or conversational client/server that can handle request/reply - as in our case. EntireX Communicator can also be used to expose XML-aware applications as SOAP-based Web services and in our landscape also provides important enterprise services such as application load distribution and security for the messaging layer.

The JEE Application Architecture
A standard JEE design is one that is typically tiered (layered) with software components distributed across the client/presentation tier, web tier, business component tier and database tier. We saw in an earlier section how the generated wrappers expose business functionality written in Natural using EntireX broker-based RPC service calls. The generated wrappers (proxies) were encapsulated (and extended) within standardized business object templates that were defined, cataloged and implemented for individual specific business use cases (the defined business interface templates for our typical business use cases are discussed in a subsequent section). The client/presentation and web tiers were developed using Apache Struts, leveraging a widely accepted MVC framework [3]. Use of core Java and the Struts framework mitigated buffer overflow and memory leak risks.

JavaServer Pages (JSPs) wrap the intended HTML layout/presentation of the data. In order to give application users a continuous feel and responsive experience, an AJAX-based model was designed to perform UI changes without a need for page reloads. Servlets (Action classes) in each business process areas were used to handle the client request thread and query the respective business component module for the required information to satisfy the request and then format the information for return to the JSP (a typical use case illustrating this interaction is discussed in a later section). Centralized validation was designed for all parameter and business rules. The Session Façade, Business Delegate and Service Adapter JEE Blueprint patterns were used at the business tier. All calls from action classes were designed to be routed via Session Façade Service objects (secured via a declarative security realm) that in turn would call individual Business Delegate POJO objects to wrap the request into an RPC call to the actual Natural subprogram via the broker-based middleware infrastructure discussed previously and subsequently translate the response up the call stack (see Figure 2). The objective of this design was to increase the indirection by hiding implementation details of calls to the underlying layers and increase reusability with high cohesion between business-tier components. Figure 3 shows the various tiers encompassing the system boundaries along with their respective communicating components. Time and resource-intensive processes (batch processes and complex calculations) were designed to be run only by authorized users and were gated through a centralized service object on the business tier to mitigate DoS attack risks.

The Business Object Interface Templates
1. Batch Value Collector (BVC)
A Batch Value Collector call is used to retrieve a large amount of infrequently changing data from Natural. Sometimes the data returned takes longer to retrieve than is acceptable for a user-initiated online call. Other times the data is very static and can be retrieved early in a process and reused later. Batch Value Collectors are singletons and execute when the web application starts, in the init() method of the "Front Controller" servlet through which all client HTTP requests are gated and run independent of user interaction.

In order to implement BVC functionality, the BatchValueCollector interface is implemented by the Business Delegate class (refer to Listings 1 and 2). (Listings 1 - 9 can be downloaded here.)The values retrieved by the call are typically stored as a java.util.TreeMap (name, value pair) instance and available throughout the scope of the application. For example, a lot of our business objects and processes work with address information and need to have a list of valid system-defined address types. Since the list of the valid address types changes infrequently on the system, it makes sense to retrieve the information early and keep it around for future use. Even if the address types grow into the thousands, users do not pay a performance penalty to retrieve the list, because it can be retrieved and cached before the user interacts with the system. The base class for all the interface implementations is the EntireX workbench-generated class for the business functionality encapsulating Natural subprogram. The generated class has a Parameter Data Area (PDA) that serves as the data holder for all the transient application data that must be persisted to or obtained from the database.

2. CRUD (Create, Restore, Update, Delete)
Representing the basic database operations, single CRUD calls interact with a single entity in Natural and, as per its namesake, creates, retrieves, updates, and deletes files or records for a specific file. For the Natural subprogram this means providing the equivalent functionality of a Construct object subprogram. In order to implement CRUD functionality in Java, the NaturalMaint interface is implemented by the appropriate Business Delegate class (see Listings 3 and 4). As before, the generated base class has a PDA that in a sense is the overlapping data model between Java-Natural and consists of business-specific database records that must be obtained from, created, updated and/or deleted. The interface model allows for first setting the key for the required records in Natural and then calling either get(), store(), update() or delete() for the file based on the key information provided. A simple example of a NaturalMaint interface in the system is the business delegate created to model the EftInstr database file and allows for obtaining (and manipulating) EFT payment information based on a fixed set of keys: the payee ID and the EFT record number.

3. Process
Process calls initiate server-side processing with a relatively simple client call. Examples of process calls are online report submission, job submission into the job scheduler, and email messaging. When a user wants to submit a report, a simple Parameter Data Area passed to Natural via the RPC call can specify the report name or type and a return status. Typically, if a similar business use case requires the amount of data passed in the PDA to be small with the return status a simple confirmation or error condition, then the NaturalProcess interface is the one that must be implemented by the calling business delegate (refer to Listing 5).

4. Browse and ScrollableList
It is common for the application to present a list of items to the user and allow selective actions on list items. The web interface will provide this type of browsing and selecting. The Natural subprogram provides the database access and next/previous key handling and the Java application handles display and user input. Its important to note that the Browse and ScrollableList interfaces do essentially the same thing: providing a list of browseable items for display on a web page, except that in the case of NaturalBrowse, a subset of the collection of items is returned per each database call, with two custom tags (next/previous) on the display JSP created to pass in new program keys based on the last and previous item browsed. See Listing 6 for a listing of the NaturalBrowse interface. The controller of the interaction, typically a Struts action class, will update the business object with the new set of keys and perform the broker call to Natural to repopulate a new next or previous set of items in the collection that is sent back to the same JSP for display. ScrollableList (see Listing 7) provides the entire collection of data at once with a pair of different JSP custom tags to handle the display and subsequent iteration over the collection. Browse is therefore used for larger data record collections as it makes sense to retrieve and cache in memory only a limited amount of data at a time, whereas ScrollableList is used for finite data collections only that can be retrieved all at once.

A Sample Interaction
An example real-world scenario is presented for the sake of illustrating the NaturalMaint business object's usage, with a request thread flow all the way from the initiating web page to the database and back. In the Payment System, a QDRO is a ‘Qualified Domestic Relations Order' and is a physical document received by the Legal staff. QDROs are binding court orders that are issued against the retirement accounts of active or retired members, and gives specific instructions for payment to an alternate payee in the case of refund, death or retirement. The existence of a QDRO binds the organization to making payments according to the terms of the order.

A model of a typical interaction is discussed. The "QDRO Case" file written in Natural is used to store and maintain QDRO Case information. A simple use case would be:

• A user from the Legal department logs into CRIS and gets a set of menu options customized for their respective work area.
• The user navigates to the "Active Qdro Cases", one of several menu options available.
• The user is asked for a customer identifier - also called clientID (usually the customer's SSN) for the system to obtain a list of the customer's active QDRO case records, which are typically presented as a browsable list of items on a JSP (per the Browse business object template discussed earlier). Our use cases typically feature using the customer's Social Security Number (SSN) as the unique identifier to access records and perform business processing.
• Once the user narrows upon and selects the individual record of interest identifiable by its unique sequence number, a new JSP is brought up that contains details about the specific QDRO case data. The user may review the case details and, if needed, try to update it by firing off the sequence of events detailed in Figure 4. In order to optimize business object lookup and subsequent persistence, a Gda class, identifiable by clientId (SSN), was created to cache all the recently used business objects into a Global Data Area business object map, identifiable by the combination of unique record keys: clientId and sequence number. For details, see Listing 8. The Gda object is then stored in a session-scoped Gdas object's collection that can hold up to two separate and unique instances of it (see Listing 9). In other words, the Gdas object holds Gda specific data for up to two separate clientIDs, a feature designed to speed up queries and access to business objects particularly when using the same clientID to perform multiple business processes.

The QdroCaseMaintAction class (mapped to the JSP form action) is first called when the updated form data is posted from the JSP showing QDRO case details (qdroCase.jsp). This action class serves as the "controller" for all interactions with the QdroCase "model" business object and the qdroCase.jsp "view." The request parameters passed in from the JSP are first parsed in the action class to obtain the identifying keys, clientID and specific sequence number for the record, helpful for locating the appropriate business object (QdroCase in this case, that conforms to the CRUD interface described earlier). The clientID is used as an identifier to obtain the Gda (containing the priorly cached business object) from the session scoped Gdas object. Next, the cached business object (QdroCase) is obtained from the Gda business object map using the clientID and sequence number identifier. Once the business object is obtained, the various fields defined in the PDA can be updated to represent the values being passed. The update() method on the CRUD business object can then be called to persist the updated data in the database, following which the action class can then create a new forward path to redirect the request, typically a view (see Figure 4 for more details).

Software Implementation
To enhance reusability and to present a modular design, the developed application structure consists of multiple business area-specific web applications packaged as individual web modules comprising of JSPs, Servlets and Action classes along with its respective business component module comprised of business objects and other POJO helper classes (see Table 1). A common utilities module contains runtime web and program utilities used by all, such as the user login and associated authentication/authorization program infrastructure. The executables .war and .jar files were packaged as an enterprise archive (.ear) and the entire assembly was deployed to a servlet-enabled application server (JBoss).

During development, standards were established and monitored to mitigate specific coding vulnerabilities relating to input validation, parameter validation, interpreter injections and session management. Web pages (JSPs) were developed to avoid client-side document writing, redirections, dynamic JSP inclusion or other insecure actions and instead achieved much of the same effects using secure server-side processing, static JSPs and Custom Tags. Front-end features that were used frequently were embedded into JSP custom tags for reuse and easy maintainability, leveraging the popular open source Struts taglib and JSTL framework. In order to avoid use of hidden fields, request attributes, and extra database queries, vulnerable to replay or request forgery attacks, all state information was stored in session that was invalidated upon inaction or logout. In order to optimize response times and prevent unnecessary database round trips, a JavaScript-based validation plug-in was designed to be used for basic web-form data input checks at the client tier while the more advanced business process-specific validation was performed at the web tier by Struts Action Forms. All user data POSTs were gated through centralized data validation routines mapped to pre-defined field formats stored in Struts configuration files. Page and Form tokens were developed to be used to prevent vulnerabilities related to page or form re-submissions leading to data corruptions at the back end.

Open source AJAX libraries were used to build user interfaces into the application. An authentication mechanism was put in place to only allow access to valid users. The system was segregated by business areas containing aggregates (independent menus) of functional processes. Mobility of the user within the application was restricted to areas specific to the user's primary department and functional responsibility. User menus were built in, configured via XML configuration files, to constrain user interactions with the system and to enable access to individual web module (see Table 1) system-specific processes using dynamically created authorization profiles. Portability of an authorization profile across different web modules (see Table 1) was accomplished using an inbuilt Single Sign-On implementation that uses session management and cookies. An administration interface was implemented to enable centralized administering of roles and authorization information. A user self-service password reset and a password aging and complexity mechanism was also implemented and enforced within the system. An application-exception chaining mechanism was developed to always Fail Secure under any condition and a centralized logging mechanism was configured using the open source Log4J software to enable various logging modes and depth.

Since the application was to be used only by internal agency users, it was required to be deployed within the internal network protected by two layers of firewalls appropriately configured by the network administrator, to minimize external threats (see Figure 5). Furthermore, SSL encryption was deemed necessary to protect social security numbers and other potentially confidential information. System development and deployment involved configuring the technology and platform infrastructure: web/proxy servers (IIS), application servers (JBOSS), database servers, Eclipse IDE on developer machines, Accurev for configuration management, automated test tools, component build and deployment utilities (ANT) and the development, testing and production staging environments. All servers were hardened by applying the latest service/security pack, securing management consoles, removing vulnerable and unused services and disabling unnecessary ports and connectors.

Conclusion
Today's applications need to be secure and must be expected to operate in potentially hostile environments. No longer should security be added as an afterthought, typically "bolted on" during production deployment time by the systems administrator, but rather it must be integrated into the development process. Security awareness and training must permeate all levels of development staff and a holistic view must be taken, one that incorporates security into the product life cycle. It is strongly advocated to approach application security as a people, process, and technology problem because the most effective approaches to application security include improvements in all of these areas.

References

1. "An SOA Case Study: Integrating Adobe LiveCycle Forms using JBossWS" by Rizwan Ahmed, SOA Magazine July 2009.
2. "Showcasing the Key Design Principles of SOA: A case study orchestrating services using open source BPEL" by Rizwan Ahmed, Java Developer's Journal, November 2009.
3. The Apache Software Foundation: STRUTS.
4. EntireX - Documentation Overview, Software AG product documentation.