At Bluedog, our seminal product, Workbench “Always on the Job!” social collaboration SAAS platform is secured the way we have architected all our three-tier Java-based web applications. We secure the application with input validation, a core authentication authorization framework based on LDAP and JINDI, configuration management that ensures testing for vulnerabilities, and strong use of cryptography. In addition, we utilize session management, exception control, auditing and logging to ensure security of the app and web services. We also secure our routers and other aspects of the network as well as securing the host servers (patching, account management, directory access, and port monitoring). Most importantly, we design our WebObject web applications securely from the get-go.

1. www.bluedog.net
Web Security 1 of 12
Understanding Our Web Security Model
The importance of the Internet as an information management and delivery technology
is well known, and the obvious advantages of the three-tier web application model
opens new avenues to exploit the benefits of this technology to generate competitive
advantage, reduce costs, and improve programmer and end user productivity. There is
a concurrent rise of internal web portals (i.e., intranets) that exist behind organizations’
firewalls -- one of the most important areas for the development of new, component-or
web-services-based applications. But security issues abound.
Looking beyond traditional client-server architecture, we will endeavor to foster
communities that link different initiatives of the project in order to ease (through
automation, work flow streamlining, and process improvement) the exchange of
information. XML and a number of related technologies are the focus as a potential
standard for cross-enterprise integration, as well as within the boundaries of a public-
sided intranet.
However, the benefits of ubiquitous web-based computing pose as many challenges -- it
magnifies challenges such as scalability, high reliability, and availability for web-based
applications. Then there are the inherent limitations of the medium itself, including the
synchronous nature of http and stateless paradigm of the web, and a vulnerable
security model. This section will address our security model, how our approach to
application design addresses concerns for maintaining customer confidential data
during development and once application development has been completed.

2. www.bluedog.net
Web Security 2 of 12
Basic Security Model
In the three-tier web application architecture, security is built-in at several levels. Exhibit
1 illustrates the nominal architecture of our security model vis-a-vis three-tiered
applications.
Exhibit 1. Nominal Architecture
Authorization differs from authentication in that authentication ensures that only valid
users obtain access to an application. Authorization is more about controlling the data
the authenticated user is allowed to obtain after entering the application.

3. www.bluedog.net
Web Security 3 of 12
Confidentiality is the mechanism for making the information available to only the
intended recipient. A systems administrator usually protects resources by creating lists
of users and groups that have the permissions required to access this resource -- the
access control list.
Auditing is invaluable when an action performed on a user’s account must be verified.
Non-repudiation is the act of proving a particular user performed some action. For
example, a user submits a data change. By using proper record keeping and audit trails,
a systems administrator can prove that the action was performed by the particular
user’s account. Designing an application for raise a flag or notify certain partied when
fraud is detected limits vulnerabilities and reduces loss by being proactive.
The fourth component for three-tier application-level security is encryption or data
integrity. This ensures that data has not been tampered with between the sender and
the receiver. Encryption ensures that no outside parties could modify the information,
which is possible when sent over the public network. Biometric, card key, or other
secondary level security could also be considered when data integrity and network
security is being architected.
Web Tier
Our applications will be architected to provide secure web server communication and
support for Secure Sockets Layer/Transport Layer Security Protocols (SSL), HTTPS,
and HTTP challenge-response authentication. Further, the web tier of the application
will support user authentication against the single-sign-on authority, may support
cookies (if desired) and database access controls for the secure handling of transaction
operations.

4. www.bluedog.net
Web Security 4 of 12
A the web tier, user access is fundamental. To achieve security here, we will start with
authentication, and maintain secure transmission of data between the client (web
browser) and web server via SSL.
Authentication is the process of entities proving to one another that they are acting on
behalf of specific identities. For example, when a user provides a user name and
password for a logon, the authentication process verifies that this is a valid application
user and that the password matches the real user’s provided password.
Two types of authentication are weak or simple authentication and strong
authentication. Weak or simple authentication involves the user providing a username
and password to be authenticated. The user provides no further authentication
information. A major problem arises when someone else gets the other person’s
username and password and a security breach occurs. Strong authentication, on the
other hand, is more secure because the user provides a digital certification or other
private means of being authenticated.
A primary goal will be protecting communication privacy and data integrity. We will rely
on Public Key Infrastructure to accomplish a substantial chunk of this goal. Creating a
Certificate Authority, putting in place a policy for using this C.A. (for SSL
implementation, and documenting the procedures and mechanisms our developers can
use to ensure web traffic communication, end user/customer privacy, and message data
integrity will be part of the infrastructure build out defined in our project management
plan. Developers will be provided the guidelines for the proper use of the C.A. for SSL
traffic. The guidelines will be presented to avoid the common implementation mistakes
that can compromise security and performance.
Cryptography will be employed (via SSL for web or graphic user interface traffic, and at
the application level to encrypt and sign data before it is sent to the database).By
working with digital certificates and a descending hierarchy based on our C.A.,

5. www.bluedog.net
Web Security 5 of 12
management and control of security will be centralized and simplified. This approach
ensures bad user data is purged quickly and easily, intrusions are more quickly isolated,
and the client has overarching control of the secure environment independent of the
developers.
Once user access privileges are known (via C.A. and LDAP authentication), we will use
cryptographic functionality (encrypting and hashing data, application of one-way
signatures to ensure authenticity of sources) in the application tier to keep data away
from unauthorized view.
Application Tier
By linking to a single-sign on authority we will code applications to provide data security
by using access control lists and password policies. We will store information about
users and groups in a Lightweight Directory Access Protocol LDAPv3 database. LDAP
is an open directory access protocol that uses TCP/IP and scales to millions of entries,
and lookups are fast A unified management of user and password data assures all
applications run off of a certified environment that is centrally managed and governed
my explicit security policies that conform to customer and regulatory requirements.
“consumer” LDAPs can be made available to other applications or modules, mirroring
some or all of the centralized data.
Application-level security will provide a means to authenticate users, define
authorization and roles based on access control lists mapped to the central user
database for those users, a mechanism to audit and have non-repudiation of
information to be processed, encryption for data security, and support for secure
transmission and data storage.
Critical data (defined as customer confidential, business confidential or legally
mandated as confidential) will be transmitted in encrypted form (using SSL), then

6. www.bluedog.net
Web Security 6 of 12
encrypted in the application before transmission to the database. Connection from the
application to the database may also use SSL encryption (Oracle and other major
database vendors support this protocol for the application-to-database connection). This
will ensure sensitive or confidential data (such as social security numbers, credit card
numbers, or passwords) will be hashed in the persistent data store, making casual
perusal of the data by DBAs or internal users impossible.
We will architect application and database components to be in compliance with the
J2EE v1.2 EJB v1.1 Java Servlet v2.2 security models as defined by Sun and the Java
community.
Java 2 security architecture with the security model, itself composed of three layers:
Java language, compiler and runtime system, and the Security Manager. At the
language layer, Java achieves security in various ways. First, Java defines that all
primitive data types are of a specific size and independent of the machine architecture.
Second, pointer arithmetic and forging access to objects cannot be done. Third, Java
provides array-bound checking.
Objective of MVC Approach -- Segregating Presentation, Business
Logic and Persistent Data
The model-view-controller design of the three-tier architecture serves multiple
purposes. Two important ones are presentation can occur in various formats,
independent of the application; and business logic is coded in the Java classes,
so database independence is maintained and scalability is enhanced. A further
benefit is that the component architecture allows organizations to build scalable,
secure, multi-platform applications as re-usable server-side components. This
architecture has three main security goals.

7. www.bluedog.net
Web Security 7 of 12
• It reduces the burden placed on the developers who working on
independent application components containing the business logic of any
enterprise application. Modules pertaining to sensitive or confidential
information can be segregated via a “Chinese wall” approach.
• This approach also allows applications to be portable across different
vendors’ servers and permits different vendors to use different security
mechanisms. For example, the reliability of Unix systems can be
deployed facing the public, while internal systems can have the
advantage of a Windows environment without the fear of compromise.
• This approach provides support for security policies to be set by the
application developers, experts in a specific operational environment or
an application assembler who provides the solution, rather than by the
code developer.
Database Tier
Access to the persistent data store from the various applications will be controlled by
assigning specific user identifiers based on the needed application role. The application,
on the protected side of the firewall, may communicate to the database(s) via secure
port, with encryption of traffic. Data may also be encrypted in the application level (see
above) before it is transmitted via the database connector (JDBC, in many cases).
Specific database controls will be implemented as well. For example, SQL Server
provides for secure connections, and can implement role-based security that limits
developer (and application module) access to certain table spaces. In the case of
Microsoft’s product, we would pay special attention to preventing so-called SQL
Injection Attacks.

8. www.bluedog.net
Web Security 8 of 12
Network Tier
The emphasis on network security will not just on installing firewalls and Virtual Private
Networks (VPNs) to prevent outside hackers from gaining access to valuable and
confidential data. We will design and enforce a traditional DMZ-style network
architecture that segregates the web (presentation) layer on Apache or IIS web servers,
and the only traffic through the firewall will be via the application adapter (leaving only
ports 80 and 443/SSL open to the outside world).
The DMZ model is proven for exposing public-accessed assets in the most secure way.
Our approach, relying on true three-tier architecture, ensures no uncompiled code is
available for tampering. Further, only HTTP/HTTPS traffic can pass to the outside world,
while web server-to-application traffic is limited to the secure side of the network.
Finally, the application-to-database traffic is further restricted.
Operating System Tier
Internet Protocol Security (IPSec) provides application-transparent encryption services
for IP network traffic as well as other network access protections in the Windows
operating system environment. Furthermore, for a Windows environment, The most
important thing we can do to help maintain system security is to stay current with
security updates. We will craft guidelines to secure Windows operating system servers
based on known security flaws and guidelines from the vendor.
In the Unix environment (and to the extent possible in other ones), we will maintain
system security by confirming latest OS versions and patches are installed , regularly
check logs and file system integrity for suspicious activity, and make regular backups.
A key way to ensure security is to limit access. Password that are strong (longer than 8
characters, mixed case and non-standard character requirements, expiration dates)
help, as do things such as: session time outs (for web applications), cookie expirations,

9. www.bluedog.net
Web Security 9 of 12
password protected screen savers, restricting access to shared drives, the ability
disable remote logons, setting permission properly, and displaying legal and user
responsibility notices before logon Just simply regularly reviewing user list and remove
unnecessary accounts ca n boost the reliability of security models.
Restricting Developer Access to Sensitive Data
For development, we will use a Content Versioning System (CVS) to control code
revision, as well as limit access to modules based on role. Our security officer will
ensure the developers who have access to sensitive data will be vetted, and procedures
will be established to grant and rescind access during the life of the project.
During development, surrogate data will be used rather than life customer- or business-
confidential data. Once we enter the Systems Integration Testing phase, the live data
will be used to populate the deployment database. Oversight on the running of SQL
scripts by appropriate personnel will be provided by our security officer.
Other Security Issues
Because we have a global view of the three-tier model, we will endeavor to apply high-
level techniques to ensuring proper access, communicating securely to authorized
persons, and controlling where data lives. One example is the proper architecting of an
auditing methodology.
Auditing and event logging enables detection of, and protection against, unauthorized
access. Furthermore, data recovery, access permissions, and other failure recovery,
responsibility and authority questions can be addressed with the robust Audit and Event
Logging methodology we will incorporate into our application and database design.
The level of granularity at which access to data can be controlled will be set during
design, but typically this includes: at the GUI by user/password access, secure

10. www.bluedog.net
Web Security 10 of 12
transmission of data via SSL, and C.A. or IP screening. At the application level, classes
can re-check user levels of access before presenting data. Transmission of sensitive or
confidential data can be encrypted, and the data itself can be encrypted using strong
algorithms before transmission or recording in the database. The database schema can
be set to control access to tables based on roles, and specific records or fields can have
access limited. By keeping security and other business logic in the application layer,
database independence can be maintained. For example, we won’t architect security
functionality in stored procedures, relying instead on routines defined in Java code.
Use of the ACL and a centralized repository for single-authority (the master user LDAP)
defines how different user categories are configured and defined for security. Role-
based and group-based security definitions are referenced in the application logic and
database schema – even if decompiled code could be modified to let an unauthorized
user to attempt to view restricted data, two additional levels of control would prevent the
physical display of data. Roles will define who has read-only, edit, or delete privileges in
the applications.
A centralized user data repository means the configuring of new users is simplified – the
systems administrator would import new user lists, configure them to groups, assign
privileges to groups in a user-friendly GUI, and maintain user data in one application.
Failover and hot site recovery impact security as well as systems performance and
scalability. Our application architecture will take into account defined service level
requirements to ensure the capability to handle user loads, maintain application
responsiveness, audit and verify data changes,
At Project Inception
Upon kickoff of the project, we will define in a project management plan (subject to
client review and approval) a systematic approach that applies our knowledge of

11. www.bluedog.net
Web Security 11 of 12
security best practices to secure web applications during development and for
deployment.
Action items when the project commences:
• Define the basic policies to ensure web application security, referencing the
motivations for each. For example, statute dictates HIPAA/HL7 compliance, so
define database schema to reflect needed “Chinese walls” to protect appropriate
customer data.
• Define the performance parameters of a threat analysis of web-accessible
assets.
• Set the SOPs to protect operating systems/file system data by using the features
in the development, test, and deployment environments. For example, harden
Unix servers by setting up security rules, policies and procedures; implement
techniques to foil common assaults used by hackers such as IP spoofing, denial-
of-service attack, and buffer overflow.
• Use one of the Java classes that implement cryptography namespace to
transform block or string data from cleartext into cyphertext. Use general security
coding best practices to ensure a secure Web application.
• Protect the portion of the web applications that requires private communications
by using SSL and guarding intranet assets with network filtering, defining which
firewall techniques will be used (such as Network Address Translation and port
control).
• Define test plans that use a structured approach to testing for web application
security in conjunction with systems integration testing and user acceptance
testing.

12. www.bluedog.net
Web Security 12 of 12
• Apply our knowledge of authentication using Secure User Identifiers (SUIDs) and
Access Control Lists to combat impersonation, and apply the concept of running
with least group/user privileges to ensure access to only those system resources
that are necessary to accomplish normal request processing.