Avoka Transact Security...

Avoka Transact

Security Architecture

Version 4.0

All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, ormechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the

written permission of the publisher.

Products that are referred to in this document may be either trademarks and/or registered trademarks of therespective owners. The publisher and the author make no claim to these trademarks.

While every precaution has been taken in the preparation of this document, the publisher and the author assume noresponsibility for errors or omissions, or for damages resulting from the use of information contained in this

document or from the use of programs and source code that may accompany it. In no event shall the publisher andthe author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused

directly or indirectly by this document.

Avoka Transact

Avoka Transact Security Architecture

Version 4.0

© 2014 Avoka Technologies. All Rights Reserved.

Table of Contents

Part I Introduction 5

Part II Deployment Architecture 6

................................................................................................................................... 71 Application Web Access

................................................................................................................................... 82 Shared Service Architecture

Part III User Security Management 9

................................................................................................................................... 111 Authentication

................................................................................................................................... 152 Account Creation

................................................................................................................................... 173 Authorization

................................................................................................................................... 184 Access Control

................................................................................................................................... 195 Security Auditing

Part IV Data Security 20

................................................................................................................................... 201 Data Encryption

................................................................................................................................... 202 Key Management

................................................................................................................................... 213 Data Storage

................................................................................................................................... 214 Data Retention

................................................................................................................................... 225 Virus Scanning

................................................................................................................................... 236 Information Assurance

Part V TransactField App Security 24

Part VI PCI Security 26

Part VII Denial of Service 28

Part VIII System Testing 29

Part IX OWASP Security Threats 30

................................................................................................................................... 301 A1 - Injection

................................................................................................................................... 302 A2 - Broken Authentication and Session Management

................................................................................................................................... 313 A3 - Cross-Site Scripting (XSS)

................................................................................................................................... 324 A4 - Insecure Direct Object References

................................................................................................................................... 325 A5 - Security Misconfiguration

................................................................................................................................... 336 A6 - Sensitive Data Exposure

................................................................................................................................... 347 A7 - Missing Function Level Access Control

................................................................................................................................... 348 A8 - Cross-Site Request Forgery (CSRF)

................................................................................................................................... 359 A9 - Using Known Vulnerable Components

................................................................................................................................... 3510 A10 - Unvalidated Redirects and Forwards

Avoka Transact Security Architecture

© 2014 Avoka Technologies. All Rights Reserved.

IntroductionAvoka Transact Security Architecture

© 2014 Avoka Technologies. All Rights Reserved. 5

1 Introduction

This document describes the security architecture of the Avoka Transact and provides advice fordeploying and operating Transaction Manager in a secure manner.

There are several important themes people should be considering as they read this document.

1. Providing a secure system is not just about the right technical architecture, but is also aboutensuring systems are installed and configured correctly, security procedures are in place and staffare properly trained.

2. The security landscape is constantly changing, and organizations must be keep abreast of thesechanges to keep their systems secure and security procedures up to date. This will involveorganizations updating their security procedures to address the latest social engineering attacksand also ensuring system security patches are up to date.

3. Most organizations have different security risks and their system security requirements shouldreflect this. Creating and maintaining a highly secure system will incur additional costs, so thesystems security requirements should reflect the nature of the risks and their potential impact onthe organization. For example a system providing a small business "Contact Us" form will probablynot have the same security requirements as a system hosting a Federal Government tenderapplications.

4. Avoka Transact undergoes continual security penetration tests by international securityassessment firms on behalf of our customer's. Through this process Avoka Transact has beensubstantially hardened. Avoka incorporates advices from a range of leading security firms,continually improving the product.

5. Security is a collaborative process. Avoka Transact is constantly evolving to meet the securityrequirements of our customers and to adopt emerging industry best practices. If you have specificsecurity requirements you need to fulfill please contact your Avoka Transact accountrepresentative so we can start a discussion. It is quite possible the system can be configured tomeet your requirements or enhancements can be developed to meet them. Also if you havesome good advice or recommendations, we would love to hear them.

Deployment ArchitectureAvoka Transact Security Architecture


2 Deployment Architecture

The deployment architecture is a critical component in developing secure systems.

It is recommended that organizations use a DMZ style deployment architecture, with layered defense indepth. System components should be deployed into isolated tiers, so if one tier is compromised, thenext tier should retains its security integrity. Access between tiers must be minimized to the reduce thesurface attack area, using firewalls with restrictions on valid ports and IP addresses.

A standard on-premise Transaction Manager deployment architecture is depicted below:

Transaction Manager Network Deployment Architecture

The standard DMZ deployment tiers include:

App Server Tier which host the business application servers

Enterprise Information Tier which host the enterprise services and persistent data

Internally each Transaction Manager server node is comprised of the following service components.



Transaction Manager Node Services

Note in a Shared Service, or Hybrid Cloud, deployment model businesses may have the EIS tier providedin a completely separate data center which Transaction Manager delivers form transaction data into viaWeb Services. Please see Shared Service Architecture for details of this deployment model.

2.1 Application Web Access

The Avoka Transact application server nodes include the Apache Web server which act as a reverseproxy ensuring only configured Transaction applications are exposed to customers and staff.

The Avoka Transact application root URLs are detailed in the table below.

Root URL Application CustomerAccess

Role

/portal/ Web Portal Yes For customers using the Self Service Portal, note the root URL is configured atbuild time.

/web-plugin/ Web Plug-in For customers accessing forms via the Web Plug-in.

/field-worker/ TransactField App Yes For customers using TransactField App application performing remote datasynchronization

/finder/ SmartForm Finder Yes For customers searching for forms

/manager/ Transaction Manager No For business, development and IT staff managing the system

/webreport/ Business Reports No For business staff running business reports

Transact applications which should not be accessible to customers (e.g. Transaction Manager or BusinessReports), should be protected by an IP Address white list so only business staff from known networkscan access these applications.

The Transaction Manager application is not XSS hardened to the same extent as the public facingapplications, as it needs to provide facilities to author and edit JavaScript and HTML content online.

Please note with standard Transaction Manager deployments there is no requirement to expose AdobeLiveCycle to external web access.



2.2 Shared Service Architecture

Organizations can deploy Transaction Manager in a shared service model where all the TransactionManager system components in a shared service data center (cloud), and enterprise integrationperformed in a separate client data centers using the Transact Integration Agent (TIA).

In this deployment model the Transact Integration Agent will pull form submissions data from theTransaction Manager server using Web Services and integrate it into the departments' businesssystems. By using an asynchronous pull based delivery model, external organizations do not have toopen their firewalls to incoming calls from Transaction Manager.

Shared Service Deployment Architecture

In highly secure shared service deployment models, it is recommended that Virtual Private Networksbe used to secure the server to server communication channels between data centers. Alternatively IPaddress white lists can be use with the shared Transaction Manager servers to prevent access fromunknown networks.

User Security ManagementAvoka Transact Security Architecture


3 User Security Management

Transaction Manager provides a comprehensive user Security Management subsystem which features:

configurable Security Managers

configurable Authentication Providers

LDAP integration support

SSO integration support

Roles and Permissions based authorization model

Multi-Tenanted organization support for administrative functions

Form, Group and Portal access control facilities for external users

In Transaction Manager there are two general categories of users:

Internal Users who generally business and IT staff supporting the system, and

Public Users who are customers, contractors or field staff using public facing applications

Transaction Manager User Types

Internal User Security Model

Internal or staff user are managed using a sophisticated security model with:

roles and permissions based security

portal or application access control

organization based access control

form group access control

The main security entities of the internal user security model are depicted in the relationship diagrambelow.



Internal User Security Model

External User Security Model

External or public users have a simplified security model featuring:

authentication

portal or application access control

form group access control

The main security entities of the external user security model are depicted in the relationship diagrambelow.



External User Security Model

3.1 Authentication

User authentication in Transaction Manager Portal applications is managed using the Security Managersubsystem, with provide authentication and authorization services.

Configurable Security Managers

A portal applications Security Manager will delegate user authentication its configured one or moreAuthentication Providers. Internally Transaction Manager uses the Spring Security framework to providelow level authentication and authorization support. Conceptually a Transaction Manager AuthenticationProvider maps to the Spring AuthenticationProviders.

http://static.springsource.org/spring-security/site/docs/3.0.x/reference/springsecurity.html

http://static.springsource.org/spring-security/site/docs/3.0.x/reference/core-services.html



Security Manager Authentication Provider

Local Security Manager

The default Security Manager provided with Transaction Manager is the "Local Security Manager". ThisSecurity Manager is configured with a "Local Authenticator" which will authentication users against useraccounts stored in the Transaction Manager database.

The Security Manager provides configurable options for the maximum number of unsuccessfulauthentication attempts, after which the user account will be locked out for a configurable period. Thisprevents automated and manual attacks to guess users' passwords. By default a user account is lockedafter 5 consecutive unsuccessful login attempts and the lockout duration is set to 15 minutes.

Security Manager Max Login Attempts Configuration

By setting the lockout duration to 15 minutes it prevents a denial of service attack on user accounts. Thesystem does not leak information about whether the user name or password was incorrect or informthe attacker that they have reached a lockout threshold. The system does not attempt to progressivelydelay the attackers login attempts by waiting on the user thread, as this can readily be used by attackersto achieve a "Slowloris" style Denial of Service (DoS) attack. High volume automated repeated loginattempts are prevented by the Apache Mod Security module.

Application login fields and account creation fields use the HTML "autocomplete=off" attribute toensure browsers do not track this information.

Unless configured otherwise Portal applications will use this default "Local Security Manager" for userauthentication. To make another Security Manager the default can be configured on the alternativeSecurity Manager. You can also configure Portals individually on which Security Manager they shoulduse.



Configuring Portals to use a Security Manager

LDAP Security Manager

The system also provides an "LDAP Security Manager" for delegated authentication to LDAP identitymanagement systems. This security manager uses an "LDAP Authentication Provider" to authenticationuser logins with the the configured the LDAP server via Java JNDI LDAP interface. This security managerwill create linking LDAP user accounts in the local database to support users form transactions, but itwill never store the user's password in the database and will always rely on the LDAP server toauthenticate users.

The LDAP Security Manager has optimized support for Microsoft Active Directory LDAP interface whichspecial behavior when performing user bind authentication and user search calls.

Microsoft ADSF Security Manager

The system includes an "Microsoft ADSF Security Manager" for delegated authentication to externalMicrosoft Active Directory Federation Services (ADFS) identity management system.



Microsoft ADSF Security Manager SSO Auth Filter

SSO Security Manager

The system also provides an "SSO Security Manager" for delegated authentication to external identitymanagement systems. This security manager use the SSO Authentication Filter to validate the SSOauthentication tokens such as SAML assertions. This security manager then uses a GroovyAuthentication Provider to create a linking SSO user account in the local database which link to theexternal identity management system.

Transact Manager supports the configuration of PKI certificates for the verification and decryption SAMLtokens.



SSO Certificate management

These features enable SSO integration wit out having to deploy Java application code or libraries.Transaction Manager ships with the OpenSAML 2 Java libraries for integration with SAML identityproviders.

Examples of these types of authentication integration include:

SAML based SSO integration with Microsoft Active Directory Federated Services (ADFS)

SAML based SSO integration with Sun OpenSSO

SAML based SSO integration with Microsoft .Net WS-Security and WS-Federation

OpenID SSO integration with Janrain

3.2 Account Creation

Transaction Manager provides a number of account creation methods.

For organization staff using of the Transaction Manager Administration Console, new user accounts canbe created in the Administration Console which are authenticated against the TM database or aconfigured LDAP service.

When new user accounts are created in the Transaction Manager Console it is recommended that the"Change Password On Login" flag is specified. This will force the new user to change their passwordafter they have logged into the application for the first time.

With the Self Service Portal and FieldWorker applications, external users can self register using theaccount creation facilities.

https://wiki.shibboleth.net/confluence/display/OpenSAML/Home



Self Service Portal User Account Creation

The account creation facility uses a configurable User Enrollment service which supports:

reCAPTCHA security checks to deter robots from creating user accounts

automated email verification

manual administrator account verification processes, with email notifications for accountverifiers.

Portal User Account Enrollment Service

The User Enrollment Service is also a pluggable system component so organizations can develop theirown customized implementations.

Please note that the user account creation feature supports both TM database managed users and LDAPbased user accounts. For LDAP user accounts, the use will need to already exist in the configured LDAPdirectory.

When integrating with SSO Identity Management providers, Transaction Manager will generally redirectthe users to the account creation facilities provided by the Identity Management system. Once the userhas been created by the Identity Management system, they are redirected back to the TransactionManager application at which point a new linking account is created in Transaction Manager.

Password Requirements

Local user accounts password requirements can be configured using the Local Security Manager. Thiscan help ensure users do not create weak passwords which are easy to guess.



The available password requirements include:

minimum length in characters

optional requirement to contain at least one character and one letter

optional requirement to contain at least one character non alpha numeric character, e.g. &*@#

optional requirement to contain at least one upper case and one lower case character

must not contain a blacklisted password value, default configuration includes the top 45 mostcommonly used password values

Security Manager Password Options

3.3 Authorization

Transaction Manager provides a roles and permissions based security authorization model for systemadministration functions.

Organization administrative users can belong to multiple roles, which in turn contain a series ofpermissions that will enable these user to access components of the Transaction ManagerAdministration Console.

The Administration Console permission sets are highly configurable with over 140 separate view, editand remove permissions for key system functions.

By default Transaction Manager provides 5 roles:

Administrator - for use by system administrators

Form Developer - for users who can develop and test forms

Operations - for staff who can monitor and manage form transactions

Organization User Manager - for staff who can manager user accounts for their organization

System Support - for technical support staff diagnosing system issues



Organizations can develop their own customized security roles to meet their own needs.

The Transaction Manager authorization model can be used in customized Portal applications if requiredas each Portal can define its own Permission set.

Configuring authorization roles and permission sets

3.4 Access Control

Transaction Manager also provides Access Control features including:

Organization Access Control

Administrative users which are assigned to an organization are only able to access forms, theirassociated configurations and transaction data for that organization. Organization administrativeusers cannot view data belonging to other organizations. This data access control is implementedat a Data Access layer in the system.

Portal Access Control

All users need to be explicitly granted access to Portal applications which feature userauthentication.

Form Group Access Control

Form Groups provide the ability to define groups of forms which are only accessible to usersbelonging to the same group. With LDAP and SSO user accounts, these users can have a mixture ofexternaly managed Groups and Transaction Manager Groups to control their access to formsbelonging to a Form Group.

Form Groups support access control to associated forms, tasks and submissions in the Self ServicePortal and Mobile FieldWorker applications. Access control permissions include:

o New Forms - access control allowing users to open new forms

o Saved / Assigned Forms - access control allowing users to open saved work group forms andgroup assigned tasks

o Completed - Forms - access control allowing users to view completed form submissions



Form Group Access Control

3.5 Security Auditing

Transaction Manager provides data access layer security auditing, which will audit all changes to keysystem entities recording which user made the change, when they did this and what changes weremade.

This feature enables administrators to track what changes have been made to specific database entitiesfor security auditing purposes.

This facility is also extremely useful for doing post incident analysis to determine what changes weremade to system configurations prior to an incident.

System Security Audit Log

Data SecurityAvoka Transact Security Architecture


4 Data Security

4.1 Data Encryption

Transaction Manager provides secure storage of sensitive transaction data and user credentials bycryptographically strong encryption.

All sensitive user form transaction data (form XML) is stored in the Transaction Manager database asencrypted BLOB values. This data encrypted with the Advanced Encryption Standard (AES) algorithmusing a 256-bit key and Cipher Block Chaining (CBC).

All Transaction Manager managed user passwords are stored in the system database as SHA-512 hashvalues, using a randomly generated salt and with greater than 1,000 hashing iterations. When usersattempt to log in, their plain text password value is hashed and compared to the hashed value stored inthe database. In this manner plain text password values are not stored in the system.

These encryption hashing algorithms are approved in US Government FIPS 140-2 and AustralianGovernment ISM:

http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

http://www.asd.gov.au/publications/Information_Security_Manual_2014_Controls.pdf

The Transaction Manager cryptographic sub-system is a tamper proof module. The Java byte code of thismodule has been obfuscated using an advanced 3rd generation byte code obsfucation system to defeatmodern Java decompilers. The cryptographic sub system also had boot loading protection, and will notinitialize if the module has been modified.

4.2 Key Management

Transaction Manager incorporates a encryption key management system for the symmetrical encryptionof user entered transaction data. Each client organization of the system has its own set of secretencryption keys. These organization secret keys are stored in a Java KeyStore (JKS) which is maintainedin the Transaction Manager database as binary BLOB record values. Access to these key stores isprotected with a system master secret key.

All organization secret key values are randomly generated 256 bit values. These secret key values arenever revealed in the application user interface or are logged to the file system. Automatic roll over ofsecret key values can be configured on an organization level. When secret keys are rolled over, a newkey created and used for new transactions, while the old keys are kept to enable access to previoustransaction data. The system does not attempt to re-encrypt transaction data when organization keysare rolled over as this may interrupt service operations

http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf

http://www.asd.gov.au/publications/Information_Security_Manual_2014_Controls.pdf



Organization Level Encryption and Key Management Settings

4.3 Data Storage

Transaction Manager also supports plug-able Submission Data Storage services, which can be used tostore sensitive user transaction data in external systems. Organizations with very high data securityrequirements can look at using their own storage service implementation to store user transaction datain their own systems.

By default Transaction Manager provides Submission Data Storage services for:

Transaction Manager database storage

Amazon S3 storage

4.4 Data Retention

Transaction Manager provides data retention policies for the deletion of sensitive user form submissiondata. These data retention policies are specified at the organization level with global system defaultsused if not specified.

Organisation Data Retention Policies

Global system data retention policy configuration is depicted below.



Configuring Data Retention Policies

All sensitive binary user form submission or form prefill data is stored in separate child database tablesso they can be excluded from database backups. This can be used to prevent sensitive data from beingpersisted to backup storage, at which point it can be very difficult to destroy.

These sensitive user data tables include:

submission_data

submission_history_data

submission_extract_data

file_upload_data

request_log_data

error_log_data

It is recommended that Transaction Manager systems which handle very sensitive data or which havestrict privacy requirements should be configured to purge this data once it has been delivered to thedelivery endpoint (back office system). For these systems, configuring the maximum transaction dataage to a couple of days will provide system administrators with a few days to recovers form submissiondata, if there is some data loss failure with the back office system.

4.5 Virus Scanning

Transaction Manager supports users uploading file attachments with their form submissions. This posesa potential attack vector for computer viruses, which could be delivered into back office systems orbusiness users. To mitigate this risk, file attachments are stored in the database in encrypted BLOBrecords and are never written to disk where they could be potentially executed.



When users upload attachments to the server, the files are immediately scanned by online virusscanners to prevent viruses from entering the system. If the virus scanner is temporarily offline, userscan still upload attachments but the form submission will not be deliverable until the virus scannercomes back online and verifies that the attachments do not contain any viruses.

Supported virus scanners include:

ClamAV

Symantec Protection Engine

Symantec Scan Engine

4.6 Information Assurance

The submission data delivery Web Services incorporate data delivery confirmation steps, where by theSubmission Delivery Web Service consumer must reply with an SHA-256 hash of the delivered form XMLdata and file attachment data to the Transaction Manager server.

All Web Service data delivery services are configured to run over SSL connections. For organizationswith very sensitive data or strict privacy requirements, web service delivery should be conducted oversite to site Virtual Private Networks (VPN).

TransactField App SecurityAvoka Transact Security Architecture


5 TransactField App Security

TransactField App is self contained user application for interacting with SmartForms on a variety ofdevices including PCs, iPad and Android tablets. This application enables known users to work withSmartForms while disconnected from networks. This is very useful for field staff working in remotelocations without any network coverages.

TransactField App has the same security requirements as the Web Portal:

users must be authenticated to access the application,

users must be authorized to access the application, and

user entered data, such as saved forms must be securely encrypted.

These security requirements must also be maintained while the application is in offline mode. Usersmust be authenticated before accessing the application and users saved form data must be securelyencrypted.

When the TransactField application has network connectivity to the Transaction Manager server.However if there is no connectivity to the server, the application will authenticate user against a locallystored SHA-256 hash of their password.

User entered data, such as saved form XML is stored in a locally database encrypted using the AES-128algorithm.

All communications between the TM server and TransactField App are performed over HTTPS, with callsbeing authenticated against the users credentials on the server.

Online Authentication

To access the TransactField application users must initially authenticate against a Transaction Managerserver. The TransactField application also support user account creation in the application. When a userlogs in with TransactField App a REST authentication service is called via HTTPS, sending the enteredusername and password.

Transaction Manager authenticates the user against the configure Security Authentication service(which could be either TM database account or a LDAP server) and responds accordingly. From thatpoint, all calls to Transaction Manager REST services are secured with standard HTTP BasicAuthentication (by including an Authorization header containing Base64 encoded credentials) andprotected from man-in-the-middle attacks using SSL. An authentication sequence diagram is providedbelow.

Field Worker with LDAP Authentication Sequence

With TransactField App and all Transaction Manager applications it is critical that HTTPS is configured forall communications.

TransactField App SecurityAvoka Transact Security Architecture


Offline Authentication

Once a user successfully authenticates against a Transaction Manager server, the users password isstored as a SHA-256 hash value in the local application device storage. On iOS and Android devicesapplication storage has security protection features preventing data access by other applications. Pleasesee the Apple iOS Security white paper below:

http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf

When TransactField App is offline, and cannot connect to Transaction Manager, users are authenticatedagainst the locally stored user credentials. The user entered plain text password is SHA-256 hashed andcompared to local credentials. The user entered password is never stored on the devices as plain text.

When offline, TransactField App compares a hash of your entered password against against a hash thatwas created (using SHA 256 algorithm) and stored with your username when you last logged insuccessfully online. The entered password itself is never stored on the device, but is used as a secretkey in memory for 128 bit AES data encryption / decryption.

Local Data Encryption

All local form submission data, user profile information, tasks and saved forms are stored as encryptedusing AES-128 bit symmetrical encryption with the user's plain text password uses as the secret key.

http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf

PCI SecurityAvoka Transact Security Architecture


6 PCI Security

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard fororganizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM,and POS cards.

Transaction Manager supports PCI DSS through its design features of never storing card holder data ortransmitting cardholder data across open public networks. Transaction Manager error logging facilitiesare designed to ensure cardholder data is also not accidentally logged in a payment error scenario.

Transaction Manager integrates with Payment Gateway providers using two models:

2 Party Model (Server to Server)Where TM makes a direct server to server call to the Payment Gateway provider to perform atransaction

3 Party Model (User Redirect)Where Transaction Manager redirects the user away to the Payment Gateway provider's web sitewhere they perform the payment transaction, after which the are returned to the TransactionManager application

Each of these models has different advantages and disadvantages.

The 2 Party Model provides a faster and more consistent user experience, as the user never leaves theSelf Service Portal. However, as cardholder details pass through the Transaction Manager systemsnetwork, the system may require PCI certification depending upon the payment transaction volumesand the Payment Gateway provider's requirements.

The 3 Party Model does not require any PCI compliance as no cardholder data passes through theTransaction Manager systems network. However, the disadvantage is that the user experience is not asconsistent across the applications and tends to be slower.

Supported 2 Party Payment Gateways include:

BizGate

BPoint

CommWeb

NAB

SecurePay

TNS

Westpac

Supported Hosted 3 Party Gateways include:

BizGate

BPoint

NAB

PayPal

SecurePay

TNS

PCI SecurityAvoka Transact Security Architecture


Westpac

WoldPay

Denial of ServiceAvoka Transact Security Architecture


7 Denial of Service

Denial of Service (DoS) attacks (http://en.wikipedia.org/wiki/Denial_of_service) can take many formsincluding:

direct attack by targeting system web servers and network infrastructure

deploying viruses/worms onto the system's servers

indirect attack such as targeting domain name servers

social engineering attacks

Each of the DoS attack risks need to be mitigated by different means. Organizations also need to assesswhether DoS is a significant risk for their system, and what level of effort should be expended tomitigate this risk.

Web Service DoS

DoS attacks on web servers and network infrastructure should be mitigated on the network perimeterpreferably using a smart switches such as F5 BIG-IP or Cisco CSS. This will help ensure the moresensitive application servers and enterprise information systems deeper in the network are notimpacted.

Avoka Transact provides layered defense against DoS attacks with:

Apache Mod Security (https://modsecurity.org/) providing a application firewall protectingagainst common DoS attacks such as Slowloris which will exhaust server resources

Transaction Manager Quality of Service (QoS) features will deflect very high request loads atconfigurable thresholds

http://en.wikipedia.org/wiki/Denial_of_service

https://modsecurity.org/

System TestingAvoka Transact Security Architecture


8 System Testing

Non Production server such as Staging, Test and Development should be configured securely.

Organizations should NOT perform system testing on systems without SSL configured or with self-signed certificates because this will invalidate system testing. This will also make it more difficult totrouble shoot configuration issues as these servers will not accurately reflect production.

Please note that self-signed certificates are generally not recognized by Adobe Reader for securityreasons, and these types of certificates also cause issues with web service integrations. Someorgnizations attempt to save a few hundred dollars by using self-signed certificates, but will then spendmany thousands of dollars and time chasing down non-existent issues during testing.

A best practice is for organizations to use sub-domains for non-production systems, for example:

https://mycorp.com/ -> Production

https://test.mycorp.com/ -> Testing

https://dev.mycorp.com/ -> Development

It is recommended that organizations set up IP address white lists so that these servers can only beaccessed from known networks.

Please Note: Wildcard SSL certificates for sub-domains can be used to save cost, however they do haveadditional risks of:

If one server or sub-domain is compromised, all sub-domains may be compromised.

If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.

https://mycorp.com/

https://test.mycorp.com/

https://dev.mycorp.com/

OWASP Security ThreatsAvoka Transact Security Architecture


9 OWASP Security Threats

Security threats to information systems are wide ranging and include:

account or identity theft

theft of intellectual property

tampering with data

denial of service

being used as an attack vector to target another system

When considering the security architecture it is important to keep these various threats in mind.

The Open Web Application Security Project (OWASP) provides a Top Ten Project which identifies themost important security issues that organizations should be addressing.

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

The Transaction Manager system addresses these Top Ten security items through its technicalarchitecture and through correct deployments.

A summary of how the OWASP Top Ten Project 2013 risks are addressed is provided below.

9.1 A1 - Injection

Security Risk

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreteras part of a command or query. The attacker’s hostile data can trick the interpreter into executingunintended commands or accessing unauthorized data.

Risk Mitigation

Transaction Manager mitigates database SQL injection attacks through its Object RelationalManagement layer (Apache Cayenne). This layer uses JDBC prepared statements for all databaseinteractions which correctly escapes input entered by the user.

Access to OS shell commands via Groovy services are prevented with by a customized Groovy run-timewhich prevents executing shell commands.

9.2 A2 - Broken Authentication and Session Management

Security Risk

Application functions related to authentication and session management are often not implementedcorrectly, allowing attackers to compromise passwords, keys, session tokens, or exploit otherimplementation flaws to assume other users’ identities.

Risk Mitigation

Transaction Manager uses best practice authentication and session management techniques to mitigatethese risks.

While this is a broad topic, risk management features provided by the system include:

user credentials (passwords) managed by Transaction Manager are stored in the database as SHA-512 hash values, using a randomly generated salt and with greater than 1,000 hashing iterations

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project



system error and security auditing logs explicitly prevent logging of user password values

user created account passwords have a configurable complexity checks to ensure users do notcreate trivial passwords. These complexity checks include minimum length, mixed alpha-numericcharacters, require special character, required mixed case values and a password value black list

HTML form login and account creation fields use the HTML autocomplete=off attribute to ensurebrowsers do not track this information

change password and change email address features require user to confirm the changes withtheir existing password

user login and user account creation flows will recreate the session to prevent session fixationattacks

session IDs are not exposed in the URL, and are maintained via HTTPS only secure cookie valueswith HTTPOnly flag to prevent JavaScript from accessing these values

all system user interactions occur over HTTPS connections

the user password recovery facility does not leak login name information to attackers

the user password recovery facility resets the password to an 8 character randomly generatedalphanumeric value

user accounts have a configurable 5-attempt lockout facility to prevent attackers from guessingtrivial passwords

the user login facility does not reveal valid user name information to attackers, or user accountlockout status

user log out facilities clear user session, and by default user sessions will timeout after 30minutes of inactivity

9.3 A3 - Cross-Site Scripting (XSS)

Security Risk

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser withoutproper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which canhijack user sessions, deface web sites, or redirect the user to malicious sites.

Risk Mitigation

Transaction Manager uses a number of techniques to mitigate this risk. Risk management featuresprovided by the system include:

portal pages use the Apache Click web application framework which automatically escapes HTMLcontent in web applications

request parameter filtering to prevent URL XSS injection

filter portal user entered values against a XSS black list, based on the OWASP XSS Filter EvasionCheat Sheet recommendations

form XML data extract value filtering against XSS values black list

prevent XSS exploit via POST of XML form prefill data

ensure session cookies are secure and use the HTTPOnly flag to prevent JavaScript from being ableto access these values

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Character_Encoding

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Character_Encoding



Please note the Transact Management Console application is used edit HTML content includingJavaScript, and does not have the same XSS black list prevention the public facing Portal applications do.We recommend that Management Console application should not be public facing, as as a minimumshould be protected from public access through an IP address white list.

9.4 A4 - Insecure Direct Object References

Security Risk

A direct object reference occurs when a developer exposes a reference to an internal implementationobject, such as a file, directory, or database key. Without an access control check or other protection,attackers can manipulate these references to access unauthorized data.

Risk Mitigation

To mitigate this risk the Self Service Portal uses cryptographically strong 128-bit pseudo randomnumbers for object references on secured and unsecured paths.

The Transact applications uses a number of strategies to mitigate this risk:

all user interaction takes place in secure authenticated sessions

data access layer security to prevent users from accessing system information they are notauthorized to view, portals

Portal and Field Worker shared submission data access control using authenticated user and formgroup access control security model

Management Console user roles and permissions security model prevents users from accessingparts of the system they are not authorized to use

organizations can also use IP address white lists to prevent parties from accessing the TransactManagement Console application from unknown sites

9.5 A5 - Security Misconfiguration

Security Risk

Good security requires having a secure configuration defined and deployed for the application,frameworks, application server, web server, database server, and platform. All these settings should bedefined, implemented, and maintained as many are not shipped with secure defaults. This includeskeeping all software up to date, including all code libraries used by the application.

Risk Mitigation

Ensuring Transaction Manager systems are securely configured is a team effort. Organizations need todesign the system infrastructure to enable security. The software needs to be installed correctly andshould be independently verified. In addition to this, organizations need to put in place processeswhich review security alerts and keep their systems properly patched.

To support this effort Avoka Technologies and Transaction Manager provide:

Transaction Manager Installation Guides which detail how to correctly deploy and configure thesystem, and include Installation Checklists which specifically cover security configuration issues.

Transaction Manager Setup Wizard helps to ensure repeatable installs and includes sensiblesecurity defaults. For example the root administrator password must be changed once theadministrator logs in for the first time.



Avoka provides quarterly Transaction Manager updates to customers, which incorporates securityfixes and system library and run time updates. The latest Oracle Java 1.7 update is generallyprovided with each release and also tested against the latest Apache 2.2.x production release.

Avoka will provide security advisories for customers if security issues are identified with specificversions of Transaction Manager.

9.6 A6 - Sensitive Data Exposure

Security Risk

Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, andauthentication credentials. Attackers may steal or modify such weakly protected data to conduct creditcard fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption atrest or in transit, as well as special precautions when exchanged with the browser.

Risk Mitigation

Sensitive data in transit is protected by a strong SSL cypher suite configuration. We recommend 2024 bitkey lengths for SSL key exchange and 256 bit AES symmetrical encryption. The server cypher suiteconfiguration must not allow the client to negotiate down the cypher strength.

Sensitive data at rest is protected by Transaction Manager secure storage subsystem. This uses acombination of cryptographically strong encryption, encryption key rollover and configurable dataretention policies to prevent access sensitive data.

Data encryption features include:

All sensitive user form transaction data (form XML, file attachments, PDF receipt) is stored in theTransaction Manager database as encrypted BLOB values. This data is encrypted with the AdvancedEncryption Standard (AES) algorithm using a 256-bit key and Cipher Block Chaining (CBC).

All Transaction Manager managed user passwords are stored in the system database as SHA-512 hashvalues, using a randomly generated salt and with greater than 1,000 hashing iterations. When usersattempt to log in, their plain text password value is hashed and compared to the hashed value storedin the database. In this manner plain text password values are not stored in the system. Repeatedlogin attempts will result in the user account being locked to prevent brute force password guessing.

Client transaction data symmetrical encryption keys can be configured to automatically rollover, so thata theoretically compromised encryption key will be constrained to a particular system client for theconfigured duration. Please note transact data symmetrical encryption keys are managed automaticallyby the system and are not exposed to any system users.

Data retention policies can be configured at a global or client organization level so that sensitivetransaction data is purged from the system as soon as it has been delivered. This limits the potentialaccess to sensitive transaction.

It is recommended that Transaction Manager systems which handle very sensitive data or which havestrict privacy requirements should be configured to purge this data once it has been delivered to thedelivery endpoint (back office system). For these systems, configuring the maximum transaction dataage to a couple of days will provide system administrators with a few days of XML form transaction data,if there is some data loss failure with the back office system.

All sensitive transaction BLOB data is stored in separate child database tables so they can be excludedfrom database backups. This can be used to prevent sensitive data from being persisted to backupstorage, at which point it can be very difficult to destroy. These sensitive user data tables include:

submission_data



submission_history_data

submission_extract_data

file_upload_data

request_log_data

error_log_data

9.7 A7 - Missing Function Level Access Control

Security Risk

Most web applications verify function level access rights before making that functionality visible in theUI. However, applications need to perform the same access control checks on the server when eachfunction is accessed. If requests are not verified, attackers will be able to forge requests in order toaccess functionality without proper authorization.

Risk Mitigation

The Transact Management Console application mitigates this risk through its user authentication andauthorization security framework.

All access to the Transact Management Console application requires the user to be authenticated andgranted access to use this application.

In addition Transaction Manager protects restricted resources through its user roles and permissionsbased security authorization framework. Users of the Management Console need to be granted roleswhich in turn will have a set configured application permissions. Only by having the correct permissionset will users be able to access restricted resources.

The Management Console permission sets are highly configurable with over 140 separate view, edit andremove permissions for key system functions.

By default Transaction Manager provides 3 roles:

Administrator - for use by system administrators

Form Developer - for users who can develop and test forms

Operations - for staff who can monitor and manage form transactions

Organization User Manager - for staff who can manager user accounts for their organization

System Support - for technical support staff diagnosing system issues

Organizations can develop their own customized security roles to meet their own needs.

The Self Service Portal and Mobile FieldWorker applications mitigate this risk through the same userauthentication framework and security authorization security model based on portal and form groupaccess controls. User must be explicitly granted access to portal applications and security groups beforethe can accessing protected resources.

9.8 A8 - Cross-Site Request Forgery (CSRF)

Security Risk

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’ssession cookie and any other automatically included authentication information, to a vulnerable webapplication. This allows the attacker to force the victim’s browser to generate requests the vulnerable



application thinks are legitimate requests from the victim.

Risk Mitigation

Transaction Manager mitigates this vulnerability by incorporating one time use cryptographically strong128-bit tokens into HTML and PDF SmartForms and also for HTML forms inside the Self Service Portal.

Self Service Portals support configurable 'X-Frame-Options' HTTP header to prevent Clickjacking attacks.

9.9 A9 - Using Known Vulnerable Components

Security Risk

Components, such as libraries, frameworks, and other software modules, almost always run with fullprivileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss orserver takeover. Applications using components with known vulnerabilities may undermine applicationdefenses and enable a range of possible attacks and impacts.

Risk Mitigation

The Avoka Transact development process reviews the system components with each release to identifyany security related issues. Each release will often include a number of updated components becauseof fixed security vulnerabilities or new feature capabilities. A manifest of dependent components ismaintained by the development team.

The most important system components are the Oracle Java Runtime environment, which is updated atleast quarterly, and the Apache HTTP web server which is updated based on a regular based dependingupon the security vulnerabilities which have been fixed.

9.10 A10 - Unvalidated Redirects and Forwards

Security Risk

Web applications frequently redirect and forward users to other pages and websites, and use untrusteddata to determine the destination pages. Without proper validation, attackers can redirect victims tophishing or malware sites, or use forwards to access unauthorized pages.

Risk Mitigation

Transaction Manager mitigates this risk by not using generic redirect or forward facilities in itsapplications.

User flows where users are redirected through login pages for authentication use session base redirectfacilities, rather than generic URL parameters which could be hijacked.

Avoka Transact Security...

Documents

Transcript of Avoka Transact Security...