Return to HomePage

Online Banking and Payment application

By Carlos Farre

Architecture

* External users / systems – customers and external partners systems
* Web Server – sits in DMZ and can be extended to use different application but the main access is through a main application called Bill Pay application.
* Application Server – sits in the corp net and has various web services which the Applications in Web server interacts with.
* Database – The application data is stored in CRM database and Yukon Database.

Authentication

* Customers
* Customers are authenticated using Forms Authentication
* User store in ADAM
* Use LDAP binds for interacting with user stores.
* Stores user authentication tickets and user attributes in the session for the user – Used for single sign on.
* External partner system
* External partners systems are authenticated using .x509 certificates.

* Yukon database and CRM database
* Uses windows authentication with trusted sub system, the web services process identity has access to the database.

Authorization

* Customer
* There is no role information, only information associated with the user is account type and that is the basis of business logic authorization.
* Depending upon the account type, the amount kind of payment etc are authorized.
* Authorization happens at the Web Server level only.

Secure Communication

* The Client to Web Server communication channel is secured using SSL.
* Communication between EPS and web server is not secured, but the messages are encrypted and signed.
* The communication channel between the web server and application server (web services) is secured using IPSec.
* The communication channel between the application server and the database is not secured.

Security Implementation

Threat Modelling

We followed Threat Modelling template and here are the highlights
* It helped us to establish the security objectives very clearly up front
* It helped us identify the scenarios very clearly hence we can concentrate on them.
* Using whiteboard approach saves lots of time and helps bring out the main scenarios which we need to care for.
* The brainstorm process was very effective and helps getting relative information quickly and was focused on your objectives.
* We used an iterative approach. Adding more detail and evolve our threat model as we continue design and development.
* We started iterations early in the design process. This helped us to ensure that we made every big decisions properly.

Remarks

* The Threat model tool from the SWI.has interesting capabilities
* It is easy to do a threat tree graphically
* It is easy to link key scenarios with threats and vulnerabilities
* It is easy to do simple DFD flow diagrams
* It is easy to link protected resources with threats and vulnerabilities
* Word format is a linear format that makes it more difficult to tie up those thinks. Are we recommending other tool, beside word?

* There are not how tos for application blocks. We need this since it is a major deliverable for PAG

Checklists

* We mostly used Code review for managed code, Code review for CAS, Code review for asp.net, Code review for web services, Check list for managed code, data access, architecture and design review

Highlights

* We were able to produce checklists depending upon our requirement and security objective. This is a major benefit so we outline the important bullet points on a security review, representing a big time gain in the process
* We are aligned with FXCOP doing the check list review. It is match case that enhances the understanding of security in managed code.
* We were able to out source the security review without losing value in the process because everybody is in sync with the checks needed to be done. This represents a cost savings, when there are people involved that are not close to you. You do not need so much validation since we discuss relevant topics from common source, using common terminology

Remarks

* We need to be better in CAS. When to use requestrefuse,optional, permissions. When to narrow scope. * What is the benefit of CAS after all??
* We need to be better in policies. When to use, what is the benefit
* We need to be better in FXCOP. How to write rules?
* How do we treat exception handling in application blocks? Meaning do we bubble up to the caller of the blocks. When do we repudiate? When do we log?
* We need to expand the checklist so to accommodate application blocks

Arch and Design Review

we used Arch Design Review and here are the sections which were of great value.
* Authorization
* Authentication
* Configuration management
* Exception Management, Auditing
* Secrets
* Cryptography