Developer

Decision Support: Issues to consider when developing a portal security solution

Follows an application development firm as it puts together a portal security solution for one of its clients


Implementing security solutions and related systems integration has always been a sensitive affair. When such an implementation has to cover an extended enterprise, it assumes more than sensitivity: It should expand the capacity of the enterprise to do more business.

One of my firm’s clients, a large and fast-expanding media entertainment business, hired us, an application development firm specializing in customer management, security, and transaction solutions, to put together a portal security solution for its dealer network and customers. For this project, it was critical to review the typical issues that the security administrator was faced with:
  1. Balancing the security needs with performance
  2. Managing multiple secure remote connections
  3. Exponential growth in user access rights to computing resources
  4. Monitoring and responding to alarms/events from many sources
  5. A lack of resources

Here’s a look at how we met those requirements while addressing the client’s concerns about working with an outside consulting firm.

Background
The client, a rapidly growing video content distributor, had plans to introduce pay-per-view, interactive TV, “t-commerce,” and broadband content to customers directly, as well as through dealers across 20 countries. The modes of delivery included wireline, cable, and/or satellite. The company wanted to extend the boundaries of the enterprise by including their business partners, suppliers, dealers, and, of course, customers in their virtual reach.

The idea was to Web-enable more business applications—such as billing, dealer/customer self-service, and financial accounting—and perform critical tasks online. Of course, the client wanted to ensure that only the authorized users could access the application. The password-based authentication mechanisms, which are predominant in today’s portals, were felt to be insufficient to ensure that the authentication/authorization of the portal user was secure and foolproof.

What the client wanted
The client was asking the channel partners, also called dealers, to use the Dealer Web Interface facility provided in the portal to conduct online transactions. Typically, a customer can walk into the dealer’s office to buy pay-TV services. The dealers then use their user names and passwords to log in to the portal and register the new customer. The dealers also use the portal for other activities, like checking their account balances and finding out the status of their various requests logged in at the portal.

Whenever the dealers logged in with their user names and passwords, the server authenticated the credentials and gave the dealer access to the database at the central server. The vulnerability in this process was that the login credentials were being passed to the server without encryption. Also, the dealers were required to remember the credentials, and no secure storage was provided.

During the login process, these details could easily be hacked as they traveled unencrypted over the Internet. Furthermore, a dealer could log in to the portal from any PC to transact business, just as you can to check e-mail in a cyber cafe.

The risks in the scenario were primarily related to the vulnerability in the Web interface access. For example, login/authentication data was prone to hacking because the pipe connecting the dealer’s desktop with the central server wasn’t secure, and could be interrupted by a hacker. (Password break-ins are a frequently reported security hazard; therefore, a plain login/authentication with username and password is prone to hacking.)

Our belief was that the client’s extended enterprise network, with its perimeter defenses, no longer provided complete protection. Server and gateway security could no longer just stay on servers; it needed to percolate down the entire network to each user PC. We wanted to provide a solution that augmented perimeter security systems by screening interactions with the corporate system, filtering e-mails, and preventing unauthorized applications from sending out data.

Anxieties and expectations
Despite these vulnerabilities, the client was concerned about high costs, uncertain timelines, and most critically, possible service interruption. The portal was supposed to be operational 24/7. The client was also cautious because of a bad experience with another consultant and wanted measured progress on this project.

To ease the client’s fears, we offered to do both prototyping, in which we did a pilot to prove the concept, and volume benchmarking, to show the client that the pilot was indeed scalable to the real thing, with 300 dealers and 300,000 customers, at no extra cost. The fact that this involved substantial effort and commitment from our side, with our own staff directly involved, and not that of another subcontractor, helped instill a sense of confidence in the client.

Our plan
For starters, we went the prototype route. We showed that the solution was scalable to address the expansion of their offerings, flexible to accommodate any mode of convergence they wish to adopt (as they make changes to their business model), and could protect their current investment made in IT and IT security infrastructure. But the solution would also keep the architecture straightforward to enable easy user-level interpretation, and an easy operation for even lay customers.

The idea was to ultimately move to a unified identity management regime that allowed single sign-on and avoided the signing-in hassles—remembering passwords, requesting administrator resets—for all stakeholders. The mandate was to bring about operational efficiencies in the enterprise connectivity in a secure and scalable manner, so that business capacity would improve with security.

We proposed a two-factor authentication (smart card and PIN) to secure the login process by the dealers and customers to the portal. The various steps in the process were smart card personalization, secure user login, secure authentication, and secure administrator login/server administration.

The initial hurdle we faced was a client perception that smart card solutions are more expensive and cause user-level resistance because the card adds to their personal inventory. We countered this through a joint ROI computation exercise. Our ROI exercise demonstrated that while the portal was more secure, it also led to benefits of streamlined system administration and lesser downtimes for maintenance. We suggested a payback period between 18 months and two years on the explicit incremental investment they were making in this exercise.

We delivered a solution composed of Server-side Secure Authentication Module (SAM), Card Lifecycle Management application with reporting capability, and Client-side SAM. This included the installation of applications and integration with the dealer/customer Web interface and the customer care and billing application at the client site only.

The solution components used XML for communication over HTTP, Crypto algorithms (RSA 1024, 2048), SHA, MD5, 3DES-CBC, and IDEA (optional), ISO 7816-compliant smart cards and readers, biometrics readers (fingerprint), PC/SC-compliant drivers, and LDAP (for RBAC and Entitlement Server implementation). Figure A illustrates the solution.

Figure A
Key elements in building a secure solution for the client


You can review our implementation stages, which involved taking the client through a four-step process, in Figure B.

Figure B
A four-step process for implementation


In our opinion, our solution wouldn’t be isolated from the rest of the applications the client was using. One way to ensure that was to provide reporting features that help improve administration of the security solution in sync with the remaining applications, like CRM/billing. For example, some events logged for reporting are card blocking and unblocking, and blacklisting. For the possibility of encryption/decryption mechanism failure, either at client or server, we provided a user management tool for the administrator to gather the above-mentioned logs and generate formatted reports.

Benefits
In this way, we could communicate several strata of savings while proving capacity management and lower levels of risk:
  • Hard benefits/savings: We indicated that there would be permanent elimination of some activities, such as entering data and administering user privileges, resulting in savings of time and money.
  • Soft benefits/savings: Our solution enabled automation of manual or semi-manual tasks, allowing for "real-time" changes, cutting errors and identifying process bottlenecks.
  • Reduced cost of ownership: This would be realized through centrally managing all system users, groups, and devices, lowering operational costs, and protecting current infrastructure investment.
  • Integrated security: Automating identity additions, changes, and deletions ensures that appropriate privileges are enforced across the organization. Companies can detect and disable intruder accounts based on their security policies.

Key lessons from the partnership
Reviewing our approach and the successful completion of the project, here’s what we took away from the engagement:
  1. Be patient. Get the client to see what you (as the consultant) think are the best practices; towards this, invest the time to secure the buy-in in a top-down manner.
  2. Do the implementation with the client. Avoid the hands-off approach that is so common in IT services implementations. This ensures longer-term ownership of the solution. For this, we used a multi-level team drawn from our members with proactive client personnel participation. Elements like the project schedule and test plans were all jointly evolved and adhered to.
  3. Hold presentations with senior level non-IT executives every two weeks to emphasize the hard/soft savings that take into account actual numbers our engineers helped collate and interpret.
  4. Effective onsite/offshore coordination plus leveraging of solution components helped hasten the implementation.
  5. The process of understanding the “as-is” business processes and suggesting enhancements to arrive at a “to-be” process gave us good clarity on future business goals and brought us closer to the users and indirect users (management).

In sum, the project involved sustainable transfer of know-how and know-why to the client, in a collaborative mode, on what was perceived to be a risky project that had to be done right the first time.

Editor's Picks

Free Newsletters, In your Inbox