Netspective | Blogs

Modernization of Administrative Process and IT Systems

Shahid N. Shah — Wed, 15 Dec 2010 04:00:27 +0000

Federal agencies are facing critical needs for information technology upgrades and enhancements. Not only are many of today’s government systems antiquated, they are also expensive to maintain and manage. The core systems have undergone so many changes over the years that the source code has become virtually obscure. Add to this tardy application response times, clumsiness in data handling, problems with connectivity and integration, lack of flexibility to add new services and functionalities, lack of web capabilities, growing license fees and maintenance costs, and the dwindling number of resources capable of supporting these systems, and you have the perfect recipe for impending disaster. There is a general recognition that IT infrastructure modernization is necessary for meeting today’s expanded federal government needs.

A modernized IT infrastructure that is architected appropriately, would be much easier for Federal agencies to maintain, and less costly to secure. Since a modernized IT infrastructure would consist of components that cost less, last longer and require less labor to operate and maintain, the total cost of ownership would also be considerably lower. In addition, modernization would improve the interoperability of government IT and provide unified real-time access to information, as well as visibility across agencies to data residing on disparate systems. This will create a collaborative environment and contribute to faster and better decision making.

What Modernization Entails

Modernization often entails migration from legacy systems and determining ways to achieve greater collaboration and interagency sharing, dealing more effectively with unstructured data, and consolidating silos of information. Modernization will involve migration of large volumes of data and complex business rules to new systems. An effective migration strategy needs to be put in place for identifying master and transaction data and moving them from existing systems to new enterprise systems or custom applications. To maintain a technological edge, Federal agencies must adopt an enterprise-wide service oriented architecture that is interoperable with systems in other Federal departments and can share information with non-traditional partners. Successful enterprise-wide solutions generally drive down the total cost of ownership while offering a single source for real-time online data that is available when needed.

Modernization: Available Options

Most legacy environments are expensive in terms of both hardware infrastructure, as well as software license fees. The need to reduce this expense is a significant driver for many organizations to modernize their legacy systems. CIOs have multiple options for application modernization, including redevelopment of applications, divestiture, and outsourcing. Redevelopment of such complex applications to be at par with modern industry standards would be a monumental task in terms of the costs involved, and the time it would take to complete development. While divestiture may meet key business needs in many cases, they often do have limitations, and here again, the cost will be prohibitive. Outsourcing may not be an option open to the Federal CIO, and even if it is, it can have serious disadvantages including loss of quality and scheduling control. There are various other available options however, that can be examined as a means to modernizing existing technologies. These include Cloud Computing, Unified Communications, Services Oriented Architectures (SOA) and Virtualization, all of which can also contribute substantially to reducing overall costs.

Cloud Computing

By using Cloud services government agencies can gain access to powerful technology resources faster and at lower costs. Government departments can save scarce resources for mission critical programs rather than spending it on purchasing, configuring and maintaining redundant IT infrastructure. Federal departments can significantly reduce their IT costs and complexities, optimize workload and improve service delivery by adopting Cloud Computing. It provides a way to increase capacity or add capabilities on the fly without investing in new infrastructure, training new personnel or licensing new software. Incorporating cloud computing into the data center consolidation plan can minimize the government’s carbon footprint, reduce IT fragmentation, improve resource utilization, and conserve electrical power and fuel.

Government agencies can transition to the Cloud at their own pace. Security risks are often cited as the number one concern while transitioning to Cloud Computing. Modernization offers a step-by-step approach that enables government agencies to move non-core functions to the Cloud first, and once that has been successfully accomplished, move core functionalities as well. Transitioning to a private cloud is one option – providing the same web benefits from within the boundary of an agency's own firewall. A private cloud enables agencies to leverage benefits like pay-as-you-go licensing and elasticity – from within their own data centers, at their own pace. Another option would be to move a single application into the Cloud environment. Moving a single application will demonstrate the ease with which applications can be transitioned to a different operating environment while maintaining full agency control over the data.

Unified Communications

New technologies like unified communications offer exciting opportunities for expanding human collaboration within organizations and hold tremendous potential for supporting business strategies that rely on increased customer self service, enhanced employee productivity and streamlined processes. Unified communication provides government workers with the flexibility to reach their colleagues and access the information they need anywhere, anytime. It enables faster, better informed, collaborative decision making, which allows governments to improve the way they serve and protect the citizens. Combining unified communications with Web 2.0 technologies, such as mash ups and blogs can enhance service delivery to citizens. When successfully deployed, Unified Communications helps organizations reach their goals and meet deadlines by enhancing communication and access to data. It increases efficiency and reduces the time taken to share information. Because these technologies are IP-based, existing infrastructure investments can be leveraged, new features can be added as and when needed, and under-utilized network capacities can be tapped. The best way to reap the benefit of Unified Communications without having to deal with the complexity of integrating and managing the different technologies involved, is to leave the heavy lifting part to a managed services provider.

Service Oriented Architecture

Service Oriented Architecture (SOA) is useful for all major agencies because it offers the flexibility for rapid deployment of new software applications with minimum relative cost impact. SOA Integration involves re-using existing legacy systems by wrapping them with SOA interfaces. SOA Integration provides Federal agencies with increased agility as legacy components can be used as part of a new SOA based architecture. It allows government departments to adapt new technologies while responding to changing user needs. SOA reduces system complexity and deployment risks through a shared development style, uniform standards and common interfaces. By adopting a service oriented approach agencies can achieve the following benefits:

Improved agility and responsiveness
Ability to support net-centric operations and secure information sharing
Ability to enhance and maintain management visibility and provide decision support
Reduction in cost of application development as well as that of operating an enterprise

Virtualization

Virtualization abstracts software from hardware and enables greater flexibility in processing IT services on different resources, at different locations, and at lower hardware and maintenance costs. In addition, server virtualization can extend the use of existing data center space and existing power and cooling capacity while increasing operational efficiency. Using a standardized platform is another option for government agencies to cut costs and boost performance. Standardization allows service providers to deliver utility IT services to a number of clients, thus helping them achieve better economies of scale. This will enable them to provide the services at lower prices.

Benefits of Modernization

Government agencies can expect to realize a number of benefits through modernization of their IT environment, including the following:

Significant reduction in cost
Reduced dependency on legacy skill sets
Elimination of data silos resulting in greater flexibility
Extended ROI from existing systems
Better connectivity and integration
Improved application response times and data handling capabilities

Legacy systems are an organization's biggest assets. The amount of data that these systems have accumulated over the years is invaluable and irreplaceable. Many Federal organizations depend on legacy systems for day-to-day operations. Though most of these systems have become obsolete and unwieldy, doing away with them altogether will be like throwing the baby out with the bath water. It is not an economically viable option. What is required is to leverage existing investments in IT applications so as to be able to address changing business requirements with agility. Legacy modernization using options like Cloud Computing, Unified Communications, Services Oriented Architectures and Virtualization is the answer.

How Adoption of Open Standards Can Benefit Federal Agencies

Shahid N. Shah — Wed, 01 Dec 2010 04:17:26 +0000

Governments worldwide are beginning to emphasize that their IT departments adopt Open Standards because of the improved interoperability, organizational flexibility and responsiveness that such an initiative can result in, and also as a means for avoiding vendor lock-in. As technology becomes increasingly an integral part of other disciplines, this new-found preference for Open Standards is driving innovation in politics, healthcare, disaster management and countless other sectors.

In keeping with the general trend towards Open Standards, many government IT software procurement policies today specify that products and solutions should support and implement Open Standards before they can be considered. However, there are several challenges to be overcome if this is to be put into practice. The reality is that, sometimes, Open Standards may not be available or are not mature enough for a required technology. Also, in some cases, the usage of a de facto standard is so entrenched that it is not practical to ignore it.

By adopting Open Standards, Federal agencies can achieve the following:

Introduce interchangeable components into their IT environments
Increase portability and scalability of their applications
Lower total cost of ownership
Improve interoperability
Gain access to better software products through increased choice
Reduce costs for switching and transferring data to different programs
Gain the ability to safeguard data over a long period of time
Reduce potential for unfair contract terms
Reduce lock-in to one system or one vendor

Standards Development

Individual standards typically are developed in response to specific concerns and constituent issues expressed by both industry and government. U.S. industry competitiveness depends on standardization, particularly in sectors that are technology driven.
Standards seek to ensure that:

Systems can be harmonized within and between organizations and across borders;
Different parties or entities can produce technologies that work together in order to foster mass adoption of those technologies by the community and to promote competition;
New players can more easily enter existing markets and manufacture new technologies or products that work with existing technologies and products; and
Consumers and users can be instantly familiar and comfortable with new systems, products and emerging technologies.

To effectively respond to the challenges posed by globalization, the emergence of new economic powers, and public concerns such as about climate change, and because of the need to stay abreast of evolving technologies, standards development organizations and the standards development process itself must be flexible as well as capable of adopting the most innovative and best performing technologies available.

Interoperability

Open Standards enable diverse products to work together. This gives governments choice among a diversity of applications from a wide range of suppliers/vendors, and leads to innovative technological developments. In the IT industry, standards are particularly important because they allow interoperability of products, services, hardware and software from different parties. Since the specifications are known and open, it is always possible to get another party to implement the same solution adhering to the standards being followed. Interoperability allows for better coordination of government agency programs and initiatives to provide enhanced services to citizens and businesses.

If Open Standards are followed, applications are easier to port from one platform to another since the technical implementation follows known guidelines and rules, and the interfaces, both internally and externally, are known. In addition to this, the skills learned from one platform or application can be utilized with less need for re-training. It is also in the interests of national security that Open Standards are followed to guard against the possibility of over-reliance on foreign technologies/products.

An interoperability framework needs to be put in place. This can provide baseline standards, policies, guidelines, processes and measurements for governments to adopt. The framework will detail how interoperability will be achieved among agencies and across borders, allowing the exchange and management of data and functionality. Combined with baseline audits of interoperability, interoperability frameworks can help create a pathway to greater interoperability through open IT ecosystems.

Baseline audit, mapping, and selective benchmarking efforts that are guided by a clear vision and goals make later policymaking more focused, effective and user driven. These efforts, if initiated with the early involvement of relevant stakeholders, will help identify systems silos that inhibit interoperability, and define areas where Open Standards are likely to have the greatest impact. Mapping standards means identifying all standards in use within and across agencies. An early mapping effort enables agencies to focus on making legacy systems interoperate and minimizes any disagreement over definitions that may impede progress.

Service Oriented Architecture (SOA)

Like in interoperability, Open Standards are the backbone of a service-based approach. In particular, a service orientation increases flexibility, modularity and choices. They ensure flexibility so that criteria and decisions are service-oriented and technology-neutral. They enable managers to combine, mix and match, and replace components without the expense and expertise of custom coding connections between service components. Service-oriented, Open Standards based interchangeable components give government organizations choices at the component level. Changes such as replacing legacy systems can be made without degrading the functionality of other parts of the ecosystem. Services can be built with modular components on different systems using a service-oriented architecture.

Improved Flexibility

By following Open Standards, governments gain new efficiencies from increased competition, access and control. Greater competition among suppliers, products and services helps governments maximize their return on investments and performance. Openness can also strengthen a buyer’s negotiating position since they have more options. This ability to choose not only lowers costs but also gives end users more latitude to set requirements and performance criteria.

The ability to see, use, implement and build from an Open Standard allows managers and users to exert more control while determining if and when they need to add functionality, swap components or fix bugs. By relying on Open Standards, managers can decide when to upgrade and who provides software support. They can replace suppliers or even implement upgrades in-house. Organizations can keep pace with changing technology, and become more efficient and effective in meeting citizen and taxpayer needs.

Other Benefits

Open Standards offer a balance of private and public interests that can protect IP with fairness, ensure clarity in disclosure policies, and promote reasonable and nondiscriminatory licensing.
Using Open Standards will also offer better protection of the data files created by an application against obsolescence of the application.
Open Standards make it an easier and, in some cases, the only possible means for local companies to participate as major players in supplying services and solutions to the government. The government can leverage Open Standards to mix and match solutions from different suppliers in order to give the local suppliers a chance.
Governments also benefit from the greater transparency that Open Standards bring to the IT ecosystem. This transparency enables organizations to determine the best balance between aspects such as protection, control, risk and cost. Open Standards allow government agencies to build on existing protocols and procedures, and to innovate on top of them.
As needs change or services expand, Open Standards can enable the evolution of a business case by allowing the future addition of components and functionality.

The Need for Building Awareness

Having a knowledgeable citizenry is necessary if governments are to sustain the advantages of open technologies, innovate and spur a society’s social and economic development. Education, R&D and training merit attention and resources in order to strengthen a nation’s knowledge base and its ability to share in innovation.

Governments must find ways to support and extend the work of collaborative communities, and where possible, formalize their role in a consultative process. User feedback, which often highlights smaller issues, may help identify new areas of growth for standards, evolve service-oriented approaches, test new designs or produce other innovations that enhance IT ecosystems. Collaborative development processes can also broadly impact openness in government and an economy, driving efficiencies, growth and innovation, as well as contribute to a society’s sustainability.

Open Standards are important to promote the wider adoption of standards and the corresponding development of interoperable and innovative technologies. There is often a degree of openness in the processes followed in the development of standards. However, it is the openness of the legal interests in standards – namely, users’ rights to access, use and share the technology embodied by a standard and its documented specifications – that is of fundamental importance in promoting interoperability and innovation.

In moving towards Open Standards it is necessary that the legal rights and restrictions that apply to standards and standard specifications are properly managed. In particular, it is crucial that copyright and patent interests are clearly disclosed to all developers and users of standards from an early stage and that the terms upon which these interests are licensed are made clear.

10Gb Ethernet: Taking Virtualization to the Next Level

Shahid N. Shah — Thu, 14 Oct 2010 05:33:41 +0000

With its huge potential for saving money and improving operational efficiency, virtualization has come as a boon to cash-strapped Federal CTOs. Not only can it substantially reduce the cost of running data centers and corporate networks through more efficient use of both hardware and software, it can also significantly reduce the number of physical devices on the network, thus considerably lowering the complexity of managing the network infrastructure. Whether it's greater performance that you seek, or reliability, availability, scalability, consolidation, agility or a unified management domain, virtualization is your best bet for supporting public sector IT modernization goals.

Virtualization will however, result in more traffic in the consolidated area. Rather than merely adding more virtual servers, what is required is to create a converged infrastructure that allows all resources to be shared. This way storage, bandwidth, and applications can be reallocated based on current workload and organizational need, without them mixing with or disrupting other partitioned resources in the system.

10 GbE: The New Thing in Networking

As virtualization efforts evolve, you run into networking challenges, and that’s the time you should begin to think about laying the groundwork for the adoption of 10 Gigabit Ethernet in the data center. The shift toward 10 Gigabit Ethernet means more than moving to a higher bandwidth. It means re-examining your entire network architecture. Higher thorough-put from the 10 Gigabit Ethernet switches allows you to connect server racks and top-of-rack switches directly to the core network, obviating the need for an aggregation layer. Now that high-speed network technologies like 10 Gigabit Ethernet have become widely available, several new solutions have been developed to consolidate network and storage I/O into small numbers of higher bandwidth connections.

How 10GbE Works

10 GbE technology is used primarily to interconnect switches and routers. By separating data and routing information, it allows you to control your own IP address routing and make the changes you want. You do not have to share your routing scheme with your service providers. And you can support both IP and non-IP based protocols. The latest 10 Gigabit Ethernet rack-top switches now support the same 48-port density as 1 Gigabit Ethernet switches, which means you do not lose valuable rack space when upgrading to 10 Gigabit Ethernet.

The primary advantage of 10 GbE technology is the sharp reduction in the number of adapters and ports required for a server. In addition to the usage of fewer physical devices, you also save valuable floor space, as well as power and cooling resources.

The Benefits of 10 Gigabit Ethernet

With applications becoming increasingly bandwidth-intensive, faster networking solutions are required to improve network connectivity while maintaining high reliability levels. 10 GbE technology provides the perfect solution to meet this requirement. In addition to increasing network speed, it also offers the following:

Potentially lowest total cost-of-ownership in terms of expenditure on infrastructure, maintenance costs and the involvement of human capital
Quick and easy migration to higher performance levels
Proven plug and play integration capability using your existing infrastructure
Familiar network management feature set that involves hardly any learning curve

Upgrading to 10 Gigabit Ethernet is a great way for Federal agencies to get better results from their server virtualization and infrastructure consolidation initiatives. It provides a significant increase in bandwidth while ensuring full compatibility with existing interfaces, thus protecting your investment on cabling, equipment, processes, and Ethernet based training. It retains your existing Ethernet architecture, including the Media Access Control (MAC) protocol and the Ethernet frame format and frame size.

But the biggest benefits of 10GbE come from having fewer servers and less storage gear plugged in. You can deploy just two 10 Gigabit Ethernet instead of using four to eight 1 Gigabit Ethernet in each server, and still achieve full redundancy for availability and additional room for expansion. In terms of scalability a 10 Gigabit Data center enables terabits of aggregate traffic without adding more layers to the network. Additionally it simplifies the network design by eliminating congestion points and reduces the need for complex QOS schemes.

Here’s a run down on the benefits of a consolidated and virtualized 10 GbE data center:

Enables flexible, dynamic and scalable network infrastructure
Reduces overall physical connection count
Provides high availability and redundancy
Improves server utilization and application efficiency
Reduces power consumption
Offers significant cost benefits

With network traffic increasing inexorably by the day, Federal data center managers need to look for faster network technologies to solve increased bandwidth demands. 10 Gigabit Ethernet offers ten times faster performance than Gigabit Ethernet, allowing you to reach longer distances and support even more bandwidth hungry applications, making it the natural choice for expanding, extending, and upgrading existing Ethernet networks. 10 Gigabit Ethernet helps you get the best out of your virtualized environment.

Virtualization: Your First Step to Data Center Consolidation

Shahid N. Shah — Tue, 12 Oct 2010 07:47:24 +0000

The Obama Administration has taken a hard look at the Federal IT infrastructure, and has come to the conclusion there’s way too much of flab that needs to be trimmed. Federal CIO Vivek Kundra has been put on the job, and he’s got his task cut out – reduce information technology costs, lower energy consumption, minimize IT real estate space utilization, bolster information security, and expand the use of cloud computing. Kundra has laid out a roadmap that proposes to:

Promote the use of Green IT by reducing the overall energy and real estate footprint of government data centers;
Reduce the cost of data center hardware, software and operations;
Increase the overall IT security posture of the government; and,
Shift IT investments to more efficient computing platforms and technologies.

One major area of concern has been the proliferation of resource hungry data centers and server farms, which currently number more than 1,100. The government has been spending billions on these behemoths annually, but many of these remain under utilized. Data center consolidation therefore is high on Kundra’s priority list. It helps to contain server sprawl and simplify data center management. It reduces the load on servers during peak hours, resulting in improved performance, availability and scalability as well as lower maintenance costs.

Data Center Consolidation

Never has there been more pressure on Federal IT to deliver higher levels of service or greater degree of availability than today. Likewise, never has it been more constrained to cut back on costs than it has now. Making sure your technology environment is efficient and effectively managed has become absolutely essential. Your data center by its very nature is where a substantial portion of your IT resources are concentrated, and that’s where you should start if you want to improve your computing environment and cut costs at the same time.

Data center consolidation means more than merely combining servers. Detailed below are a number of other factors that go into it, all of which translate into an opportunity for reduced cost and greater manageability.

The problem of multiple physical locations: By reducing the number of physical locations of your data centers and combining their operations, you can substantially reduce cost overheads. While multiple data center locations used to be a way to meet the need for disaster recovery and business continuity, there are better ways to address those concerns now.
Server consolidation: This not only implies utilizing unused server capacity, but also analyzing the historical CPU and memory usage patterns of the applications running on them, and consolidating them in an intelligent way.
Infrastructure management: This includes creating more efficient networks and better storage management. It also includes utilizing shared services to the extent possible.
Optimizing space and power utilization: This will result in a greener computing environment as well as in substantial cost savings.
Managing people and processes: This will perhaps be your biggest challenge, because while it’s quite a straight forward matter to switch servers, bringing your personnel up to speed on those changes can be more tasking.

The Benefits of Data Center Consolidation

By simplifying and consolidating your data center environment, you achieve several goals including the following:

Better manageability
Reduced costs in the areas of human resources and infrastructure facilities
Improved service levels and higher availability
Minimization of impact from external factors

Server Virtualization: The Best Way to Consolidate Your Data Center

Data center consolidation can best be achieved through server virtualization. It enables your physical servers to leverage unused capacity to support multiple workloads on simultaneously running virtual machines. It can thus help you significantly reduce the number of servers in your data center, which in turn will result in less hardware, less rack space, less cabling, less cooling, and less energy being used. This translates into lower capital costs and a substantial reduction in your ongoing maintenance expenses as well.

But virtualization is not merely about reducing the physical footprint of the servers in your data center and the resultant cost savings. It’s more about dynamically launching applications, reducing latency and expediting disaster recovery. It’s about reducing the number of tiers on your network, aggregating traffic and adding multiple devices that work like one — all of which will contribute to simplifying your operations and ensuring your network’s performance and latency are at acceptable levels.

The Benefits of Virtualization

Server virtualization can bring you a host of benefits, some of which are enumerated below:

Virtualization can help you maximize network asset utilization.
Fewer physical servers result in reduced capital and operational expenses.
Fewer servers also mean reduced energy requirements and a lower carbon footprint.
Virtualization can substantially reduce your rack space requirements and capital expenditure on real estate.
By having each application deployed within its own virtual machine, you can prevent one application from impacting another when upgrades or changes are made.
Virtualization allows you to develop a standard virtual server build that can easily be duplicated, thus speeding up server deployment.
Virtualization allows you to deploy multiple operating systems on a single hardware platform.
Virtualization allows you to deliver computing resources on demand, and seamlessly move data to any location on the fly.

Federal agencies would do well to shift focus from merely maintaining their server farms and data centers on which about 70% of a typical IT budget is being spent today, and instead focus their attention on efficiency and innovation, and on improving the availability of their IT resources and applications through virtualization. They should look at building virtualized networks with the ability to scale across hundreds of interconnected physical computers and storage devices. This will not only result in enhanced performance, security and availability across the board, but also in the lowest TCO over the long term, and in saving billions of dollars of taxpayers’ money.

How to plan for disaster recovery in healthcare and other data critical environments

Shahid N. Shah — Mon, 27 Sep 2010 04:05:03 +0000

In March 2010, exchange of patient medical information at VA-DOD had to be shutdown because errors kept popping up. In May 2008, heavy flooding forced evacuation of 176 patients from Mercy Medical Center in Cedar Rapids, Iowa as flood waters and sewage seeped into its basement. They barely managed to save their medical records. In May 2007, a massive storm ripped through Greensburg, Kansas and razed the Kiowa County Memorial Hospital, along with 95% of the town. The patients and staff were rescued. It was initially thought that all 17,000 patient records had been lost. After searching through the rubble they were fortunate to find that most of these were secure in a file cabinet. These were close calls, but umpteen such events keep happening, and it’s not always that luck is on your side.

Like with every other segment that relies heavily on information technology, ensuring the availability of data is of paramount importance in the healthcare sector, more so because people’s lives depend on it. In fact, DR ranked top on healthcare providers’ IT shopping lists according to a recent survey on spending priorities of the global healthcare industry, with 44 percent considering it as their top IT investment priority. Moreover, Federal mandates such as the Health Insurance Portability and Accountability Act (HIPAA) and the Joint Commission on Accreditation of Healthcare (JHACO) regulations also require healthcare providers to have data backup, DR and emergency mode operation plans in place.

Building a Disaster Recovery Plan:

With hospitals, insurance companies, laboratories, physicians’ offices, clinics and imaging centers continually accessing the system to add or recover data, ensuring information availability is a very critical need. Even an hour of downtime can have severe repercussions and could negatively impact patient care, apart from causing a lot of other collateral damage. Two key metrics on which you should base your Disaster Recovery plans are the Recovery Time Objective (RTO) and Recovery Point Objective (RPO). These metrics define the allowable down-time and the allowable data-loss per application. The smaller the RTO and RPO window is, the more complex and expensive the recovery plans become. Given below are the basic steps to be followed while building your DR plan:

Secure commitment from top management for allocating adequate time and resources to develop an effective DR plan.
Establish a planning committee that includes representatives from all functional areas of your organization to oversee the development and implementation of the plan.
Perform a risk and business impact analysis taking into consideration all possible disaster scenarios including those arising out of natural, technical and human factors, and rate the probability of their occurrence on a scale of 1 to 5.
Prioritize critical functional areas that are required to continue operations in the event of disaster.
Evaluate various backup options available and identify one that is practical and economically viable for your organization.
Collate essential information such as software / hardware inventory, storage location inventory, backup position, notification checklist, and communication protocol including contact numbers. Using pre-formatted forms helps you do this faster.
Document the plan incorporating step-by-step procedures to be followed and assign responsibilities to appropriate team members for key functional areas such as administrative actions, facilities control, logistics management, customer support, system backup, and restoration.
Test the plan to evaluate the reliability of backup facilities and procedures and identify areas that need modification, if any.
Secure approval of the plan from top management.
Train all personnel involved in backup and recovery procedures. Modify plan from time to time taking into account changed scenarios

Currently available DR options:

Listed below are some of the data backup and recovery options currently available. Choose one that is appropriate for your organization.

Tape backups – can serve as a second backup source stored in offsite locations, but are risky, slow and unreliable.
Disk-to-Disk technology – more secure and convenient and can automatically back up from different locations. However, on the downside, disk is more expensive as a storage medium than tapes.
Vaulting – automatically backs up select files at scheduled intervals.
Mirroring / Replication - this disk-to-disk process simply creates a data copy between two disk platforms. When trouble strikes the original, data can be restored from the replicated version or possibly even accessed directly from there. Can restore a crashed computer system within hours, instead of days.
Storage Area Network (SAN) – usually found to be reliable, but troubleshooting can be a Herculean task, proved as recently as last month with the massive outage at Virginia Information Technologies Agency’s Storage Area Network at Richmond.
WAN Optimization – bandwidth friendly, this technology can move tons of data and meet strict recovery requirements.
De-duplication – Often called ‘intelligent compression’ or ‘single – instance storage’, it is designed to minimize use of storage space, and looks for repeating patterns of data at the block and bit levels. After an initial backup, only changed blocks are written to disk during subsequent jobs, thus consuming significantly less storage space.
Continuous Data Protection (CDP) – continuously captures data modifications and stores changes independently of the primary data, enabling recovery points from any point in the past. Offers fine granularities of restorable objects to infinitely variable recovery points.
Snapshot – With snap shot technology, data recovery takes place as fast as the backup process. It creates incremental and differential images with almost zero latency, so there is no need to shut down system applications.

Practical tips to improve data availability:

Store the data in an all-disk environment, with the newest or regularly accessed data stored in higher-end disk storage devices, and unused or less critical data stored and archived in lower cost disk storage devices.
To ensure business continuity, replicate the data across different data centers so that if one data center goes down, the other data center kicks in with zero disruption.
Protect your network from infiltration by subscribing to network security. Choose from the numerous security seals available online to perform standard and advanced audit of your system to keep it secure against hacking threats.
Ensure 24x7 monitoring and management as well as onsite / remote troubleshooting.
Conduct regular disaster recovery drills and periodically test your disaster recovery plan
Establish downtime procedures and have carefully drawn out medical treatment protocols in place to switch to during automation failures.
Have subject matter experts review networking design, technologies, components and requirements. They can help support Information Availability goals during network outages, especially prolonged ones.

A robust DR plan is like a healthcare plan which guarantees that you will come out fine in the end, should calamity strike. Bad choices can fritter away scarce dollars, risk regulatory compliance, and fail to deliver access to your backups when most needed. Simply put, not having a good DR plan in place is courting disaster.

How to improve SAN reliability

Shahid N. Shah — Wed, 22 Sep 2010 05:33:17 +0000

Recent times have seen frequent data center outages that have seriously affected the day-to-day lives of ordinary citizens. The latest to hog the headlines was the one at Virginia Information Technologies Agency’s (VITA) Storage Area Network (SAN) located at a large suburban Richmond Computing Center. The problem began on August 25, 2010 with the crash of a pair of three-year-old EMC DMX-3 memory cards. Technical glitches that grew from there soon mushroomed into a weeklong ordeal that affected 485 of the 4800 odd servers at the Center. The outage paralyzed some of the state’s core agencies and left Gov. Bob McDonnell fuming, prompting him to institute an independent inquiry into the incident. Northrop Grumman that had won the $2.4 billion 10-year contract to manage VITA’s data centers had a very irate administration on its hands, and plenty of explaining to do.

The VITA incident came close on the heels of another major SAN outage that hit the Kansas Department of Health and Environment crippling the functioning of initiatives like the Kansas Immunization Program; the Kansas Women, Infants and Children program; Bureau of Surveillance and Epidemiology; Health Occupations Credentialing; and the Child Care Program. Though these are isolated incidents, they have sparked serious discussion on whether SAN is really the answer for a flexible, high performance and highly scalable storage environment.

Why troubleshooting SAN is such a complex affair.

SAN is essentially a networked pool of high-speed storage devices connected to servers through special SAN switches, allowing rapid data backup and restore, as well as movement and sharing of data between multiple servers. What makes troubleshooting SAN blackouts and brown-outs a daunting task is the increasing complexity of SAN hardware, as well as the multitude of devices and services that exist between the application servers and the storage equipment today.

Start with your Servers

Servers make up a major portion of the SAN component stack, and that’s where you should start looking when troubleshooting performance issues. Current SAN architectures use multiple, independent paths to access RAID-protected data. And with the multi-pathing software being hosted on the servers along with the volume manager, the operating systems, the HBA drivers, and the HBA firmware apart from a host of other things, there's a lot that can go wrong with servers. Unless you have each of these components configured as specified by the storage vendor, trouble is just waiting to happen.

Regularly update documents

Documenting the SAN topology and defining the performance baselines is an area you should focus your attention on. Capacity growth over time can bring in added complexity, leading to unacceptable performance reductions. You should document these changes to the SAN environment prior to implementation, and the performance baselines must be suitably updated. You should back up and store the switch configuration after every change to the SAN environment, preferably using an automated script. This will enable you to roll-back quickly in case of a mess up while executing the change.

Provide real-time access to traffic on SAN links

SAN performance monitoring is a strategic component that should form an integral part of your SAN implementation initiative. Switch and storage management tools provide summary and configuration information about the SAN, but they are blind to the multiple layers of traffic on the SAN links that can impact performance or cause an outage. Your engineers should be allowed non-disruptive access to the multiple layers of traffic on SAN links to conduct real-time analysis if they are to minimize outages and slowdowns. They should be equipped with proper tools and backed by supporting processes to track down critical SAN problems such as application I/O slowdowns, fabric bottlenecks, and device failures at any layer in the protocol stack.

Use metrics-based measurement

Metrics-based measurements are objective and repeatable. They accurately reflect network and application performance, and point the way to remedial measures that you should take to rectify problems. It is also advisable to have a metrics-based automated response system in place. Such systems trigger alarms to warn you when performance deteriorates beyond acceptable threshold limits, and will automatically shut down the device that caused the incident, while simultaneously collecting all possible data on the instance to help in the troubleshooting process.

Fundamental preventive measures

Suggested below are some fundamental steps that you ought to take to prevent data outages and minimize their impact in the event of occurrence:

Define a contingency policy clearly defining its objectives, scope, key resources assigned, and their roles and responsibilities.
Conduct a business impact analysis (BIA) taking into consideration the availability and performance requirements, and the possible repercussions of failure to adequately meet those requirements. Prioritize critical IT systems and components on the basis of this analysis.
Identify and put in place preventive controls and measures that reduce the probability of disaster occurring or reduce the effects that system disruptions can have on routine functioning of your organization.
Develop recovery strategies based on the types of disasters that you need to be prepared for, and the criticality of various IT systems and components to ensure quick rebound following a disruption.
Develop an IT contingency plan that provides detailed guidance and procedures for restoring a damaged system.
Submit the plan to rigorous tests to identify gaps in the plan. Provide intensive training and conduct regular exercises to keep recovery personnel always in a state of readiness.
Update the plan periodically to keep it current with system enhancements.

Even with these preventive and precautionary measures in place SAN failures can still happen, leaving a lot of stranded data that will be lost. The only option you have then is to fall back on to Plan B, which is to rebuild the lost data from scratch. This is not a very exciting prospect I concede, but you don’t have much by way of choice.

Why Clients should take a closer look at SOWs

Shahid N. Shah — Mon, 06 Sep 2010 09:59:22 +0000

One very important aspect of successful project management is the creation of a Statement of Work (SOW). A Statement of Work can be defined as a narrative description of the products and services to be provided to a client under contract. Basically the SOW tells “what” needs to be accomplished rather than “how” it is to be accomplished, and clearly defines the scope of the project. Getting everyone to agree on the scope of a project at the very outset is important because it helps in minimizing scope creep. Scope creep occurs when new functionalities or requirements not envisaged in the SOW are introduced into the project plan. Uncontrolled scope creep can result in projects overshooting budgets and schedules. Having a clear understanding of the scope of a project will also provide clarity on the expected outcome of a project, and can help in avoiding misunderstandings, disputes and rework.

A statement of work should also clearly define the roles and responsibilities of various stakeholders involved in a project. The service provider and the client should take care to ensure that the SOW accurately reflects the specific tasks and obligations each party will have to fulfill in the course of project implementation.

From a technical point of view, a statement of work should define the action items that need to be completed and the deliverables that need to be produced as they relate to technology, equipment, and systems management. It should clearly specify what exactly needs to be done, what technologies will be needed to get it done, and what type of technical support needs to be made available. The topics being addressed will vary depending on the nature of a project. The SOW for an IT infrastructure project would for instance clearly specify the individual pieces of equipment and hardware required for the project. A software application development project would specify the technology to be used, the coding standards to be followed, the development methodology to be adopted, the type of validation to be carried out and so on.

Properly developing and managing a statement of work can be challenging, but it is essential for getting any project on the right track and keeping it there. It sets the standards for effective project management and ensures that the project meets the client’s established requirements and objectives. Not having a proper SOW can result in project failures and negative financial fallouts. Taking the time upfront to develop a detailed SOW and using that to manage a project throughout its lifecycle, will go a long way in averting project failures. A typical SOW will include the following:

Project Scope - The objective of the scope document is to ensure that the vendor and the client are on the same page as far as understanding of the project and its outcomes are concerned. The scope document places boundaries around the project, identifies a high level schedule, and broadly outlines the rolls and responsibilities of various stakeholders in the project throughout its life cycle.

Project Approach - This section of the document describes how the vendor plans to go about executing the project, the methodology they intend to adopt, and the engagement model they intend to follow while delivering on the project. It will lay down a road map that will lead to successful completion of the project.

Resource Allocation - This section will identify the resources who will be engaged on the project, and what their designations will be. It will include brief resumes of key personnel and an organizational chart showing the reporting structure. It will identify the point of contact for interaction with the client. It will also spell out what portions of an assignment will be done onsite, and what will be performed offsite.

Roles and Responsibilities – Clarity regarding roles and responsibilities is essential for the successful completion of projects. The SOW must provide that clarity, leaving no room for passing the buck. Key areas that need to be addressed are people, technology and processes.

Implementation Steps and Effort Estimation – This section will define the specifics of the work plan to a level of detail that will help the client understand how the process will work. It will include key milestones and estimated timeframes for achieving them. It will prioritize the tasks to be completed and evaluate the effort required for each task, based on which cost allocation can be determined. Proper sequencing of tasks will help reduce unforeseen costs.

Period of Performance - The period of performance is the term of the contract. It must be realistic. The performance period is usually longer than the estimated scope of the effort. One should ensure that the period of performance is compatible with clauses used in other parts of the contract agreement.

Deliverables - This section outlines specific outcomes and projected deadlines of a project. Sufficient details should be included in this section to provide a clear picture of the deliverables.

Acceptance Criteria – This defines the parameters that will determine whether or not a product or service is acceptable. Having this consensus upfront will ensure that all parties involved in the project understand and agree to the specifics of the project.

Costs - This section will unambiguously state the agreed price of the project, and can include penalties that may be imposed for failure to reach specific milestones. Clarity regarding this will prevent misunderstandings occurring later.

Billing Rates – This section is specifically for contracts awarded on a Time & Materials basis. The SOW should clearly specify the hourly rates for all categories of resources engaged on a project.

Payment and Invoicing - This part of the SOW defines the billing cycles and specifies the mode of payment, payee related information and the period within which the payment should be made. If there are any specific formats that should be followed while raising invoices, that also should find mention here. The tax quotient of an invoice should be shown separately in the invoices.

Assumptions – This section describes the assumptions based on which the service provider has submitted the SOW. Project assumptions provided by the service provider should be carefully examined to ensure they are acceptable.

Following these simple guidelines while accepting a statement of work will minimize the risk of failure and help clients get the expected results from their projects.

If engineers or database administrators can access your data, it’s not secure

Shahid N. Shah — Fri, 03 Sep 2010 07:33:23 +0000

There is a general misconception in the IT community that their database servers are somehow their most secure systems and that because they are secure their customers’ data and their own financial information is safe. Let me clue you in on this is a dirty little secret: many databases are neither secure nor safe from data tampering or theft. Although lots of data may be stolen by hackers for identity theft, a great deal of other data theft occurs from insiders who could benefit from sale of such data. And, when insiders do it there’s almost no way to trace their movements if they’re smart.

In most organizations database administrators are trusted with enormous amounts of responsibility, only one of which happens to be data protection. In many organizations software engineers and other IT consultants have direct access to databases as well. In a complex environment there could be literally dozens or hundreds of technical people that have direct access to healthcare, financial, and other private information with little or supervision.

Shared (application) accounts on databases are painfully (and sometimes negligently) common. Shared (application) passwords are very common in thin-client or web based applications because it’s a design pattern followed over an over again: many web users connect to a single web application and all those web users connect through a single, pooled, database connection. Is this a bad thing? Not if you do follow some common sense rules and practices. If someone did access the database with a shared/application account and made changes, performed queries, etc there would be no way to know who it was or how it was done.

If that weren’t bad enough, production databases are often copied and used for debugging, performance testing, integration testing, or other QA activities. This means there are tapes, ZIP/TAR files, and other files with lots of private, privileged, patient data sitting around in people’s drawers or cabinets. Backup copies of production databases are necessary for debugging and QA. None of the uses seems out of line or improper – but, we need to be careful.

In this article I will present some questions that you should ask your engineers and database administrators. I won’t be supplying any answers just yet (this is a teaser article). So, start by asking:

Does your database use shared accounts to allow multiple individuals to connect to the database using a single account?
Does your database use a single account to allow unfettered access by a single application or do various functions (read/write/admin) of the apps have their own accounts?
How are you protecting the data that is duplicated for use in QA or by engineers? How about for debugging?
When you copy data for use internally Is it being deidentified and cleaned first?
Are backup tapes logged in and logged out of secure compartments or can just anyone get access to them?
Does your database have all information (passwords, SSNs, test results, salary records, etc) in plain text or is it encrypted?
Are you using one-way or two-way encryption in those cases where it is encrypted? How do you manage public/private keys?
Is your database server on virtual (private, non-routed) LAN segment with limited access from all other systems?
Who can ping your database servers? Anyone or just particular servers?

These are stimulation questions, not to be seen as a comprehensive checklist. After you’ve stimulated some thought, check back later for the next article in this series that will guide you in how to take those answers and create a stronger data fortress. In the next article I will present some solutions (some easy, some hard) for how to better protect data, especially from insiders who can do the most damage.

Ship It! A Practical Guide to Successful Software Projects

Shahid N. Shah — Fri, 27 Aug 2010 08:02:20 +0000

This article is written by Abhay Bakshi, who put together a book review of Ship it! A Practical Guide to Successful Software Projects. I like the book and what Abhay thought about it and I thank him for sharing his views.

This is not solely a technology book or a software development methodology book – it rather asks the reader to be practical or down to earth when participating in a software project and when making choices and implementing them. The book talks about authors’ experiences in handling simple and complex software projects.

This book is kind of small(er) in size. I think, that’s good and keeps the boring, heavier aspect away. It consists of three major parts:

Tools Available to You (Chapter 2)
Techniques that You Can Adopt (Chapter 3)
Tracer Bullet Development (authors’ own process that is comparable to RUP or XP) (Chapter 4)

The book contents read as if Jared is talking to you. One has to feel the author’s passion. But, more than the passion, I would say that the contents of the book are quite genuine. Jared and William have written in a wholehearted fashion about their techniques. You get a sense that both of them have worked on a reasonably high number of software projects, and have done hands-on development before they accepted their team lead positions.

A software developer keeps moving up the ladder in his (her) career. Once a team-lead, he faces new challenges, may get squeezed between the two layers viz. his team members and his upper management. Those kinds of dramatizations/scenarios in real life are available in the book. They sound like story-telling. That’s entertaining. Keeps your interest. Some other parts are only straight-forward though, at times read like pep-talks!

The Ship It! Effect

In the last three weeks (after I finished reading the book), I wanted to see how much effect the toutings in the book would have on my work activities. I thought that it would be a right test for this kinda book.

I am now happy to say that the book has helped. I also have to give myself partial credit because during this time, I have kept revising the ideas from the book constantly in my mind. Let me say, I have started using The List, and there are more things for me to do in that direction.

There are a few things that the book could improve on, I am confident; but, as is, this is one good book.

The Technical Aspect

The book is technical at its core and talks around the technicality. Here are some interesting details that the book covers:

Scripting your build process
Continuous Integration with tools like CruiseControl
Issue Tracking
Automating Tests with Mock Objects
Various tools and authors’ first hand experiences
The Wiki use of The List
Impressive team building experiences
Software Development method (Tracer Bullet Development)
Six Appendixes with a lot of reference URLs
Author also clearly differentiates between what he has read, and what he has only 'heard' about in his references. I think, that’s good for us to know.

At the end of each section, the book provides goodies such as "How to Get Started", "You’re Doing It Right If…", and "Warning Signs". Those are helpful.

Where the Book Can Improve

As for the author’s writing style, there are some sections where the authors could add some more real-life ‘conversations’ or real-life ‘stories’. For example, ‘X did this, we talked to X, X listened or didn’t, and eventually X got better or suffered losses’. People love stories. If there is another edition, I would request that more ‘stories’ be added.

One other thing that the book does not put as much weight on is the factor of ‘corporate politics’. Sometimes, you get a feeling that author wants to pause a moment and weigh the corporate politics factor in, but, he doesn’t.

No doubt, discipline as touted in the book will work for everyone. I kind of believe that discipline in general is contagious (that is, if somebody notices for a long time that I am being more disciplined and being more productive that way, then they will also try to mimic my habits), but there are still some factors (politics, jealousy!, and more) in the real corporate – whether smaller or larger – that tend to delay your possible adoptions of best (useful) practices.

Lastly, as for the editors, I also think the presentation can be arranged in a better way. There are "Joe Asks…" and "Tip xxx" kind bulbs, but certain advanced pieces of the content deserve just some more effective highlight. I don’t work as a presentation editor, still I can’t help but feel: some small unknown and necessary leg of higher quality presentation is missing. For $19.77, I can’t complain much though.

Overall

The book price is apt. You will start benefiting from Day One; and you will only continue to benefit further if you keep revising the contents and keep implementing ideas from the book. I will be trying to get myself tuned with the methodologies mentioned in the book.

Don’t forget to do network simulation in all your testing efforts

Shahid N. Shah — Fri, 20 Aug 2010 07:44:16 +0000

I’ve noticed that most of my clients have finally been convinced that unit testing and regular automated acceptance testing is a “good thing.” However, I’ve noticed that load/stress testing, while moving up in importance, still has a long way to go. Even those doing load testing, though, forget to do proper network simulation to make sure that their tests will valid with “real world” network traffic.

So, the simple advice is to be sure to use network traffic generators and network load simulators when testing your software. A good option is something like Simena. It’s not expensive and works well.

Technical leadership advice

Shahid N. Shah — Fri, 13 Aug 2010 07:36:31 +0000

Many of my younger colleagues often ask about what some of the most important leadership aspects are for technical managers like team leads or architects. There are no hard and fast rules but here are some things I’ve learned over the years:

Make Decisions. This is one of the most important aspects of leadership — just making a decision and not analyzing for weeks or months. No amount of evidence or information will ever “be enough” and at some point you’ll need to make a decision. Your team can see if you are timid or if you take risks. Leadership is about decision making and if your decision making skills or risk taking ability are limited, don’t bother trying to lead. I’ve seen many architects and so-called “team leads” that try to get their bosses to make their decisions for them so they don’t get in trouble for making “the wrong ones”. Big mistake.
Lead by Example. Leadership is about direction and if you want to lead, you’ll need to make sure you take charge and establish that you know where you want to go. But, be prepared to demonstrate that you do what you ask your team to do. If you ask everyone else to do something but don’t do it yourself, your team will lose respect.
Be transparent. You work with bright people and although they may not be your equals in experience or knowledge, they will know when you are making decisions based on whim or reason. If you can’t explain your decisions in a way that your team can comprehend then you’re not a good leader.
Mentor. Good leaders create the next group of leaders, not just bark orders. If you’re not regularly mentoring and training, you’re not doing your job. And, if you mentor well you can let your team make many of the decisions without you and you’ll be able to trust that their decisions will be as good as yours.
Be inclusive. You’re the leader and can make all the decisions and everyone knows that. But, if you’re not including input from everyone you’re losing valuable data and a chance to build a cohesive team.

Independent Verification and Validation: The NASA Approach

Shahid N. Shah — Fri, 06 Aug 2010 07:38:26 +0000

Very few of us deal with the kinds of problems that engineers at NASA face — except for perhaps other engineers working in safety critical fields like avionics and medical devices. I live nearby NASA’s Goddard Space Flight Center (GSFC), which is home to one of the most advanced software engineering labs in the world. As you can imagine, they take their engineering processes very seriously so when they put together an event open to the public I usually attend.

Recently they put together a talk on Independent Verification and Validation: The NASA Approach. This presentation described how verification and validation is executed within NASA. It "described what IV&V is and what it is not, the process that NASA uses to determine what projects the IV&V Program will work with, the approach that the IV&V Program takes to planning the tasks to be executed and how those tasks are executed."

It’s easier to get into software than to get out

Shahid N. Shah — Fri, 30 Jul 2010 07:40:59 +0000

We’ve all seen it: we spend weeks or months in the "sales and demo cycle" for our applications. If we’re lucky we consider all workflows, if we’re even luckier we test drive the UI and make sure training goes smoothly, if we’re smart we also try to ensure that deployment will be easy. However, what we all seem to forget is to figure out how to get out of an application or system after it’s been installed for a while.

Why is getting out important? Because every application becomes "legacy" sooner or later. Every system will be replaced or augmented at some point in time. The cost of acquisition (”barrier to entry”) is well understood now as something we need to calculate. How about the barrier to exit or switching cost? Do we calculate that when we decide what systems to purchase? Why not?

If you can’t answer the “how, in 24 months, will I be able to move on to the next-better technology or system?” question then you’ve not completed your due diligence in the sales cycle.

When preparing an RFI or RFP, ask vendors specific questions about how easy it is to get out of their technology (rather than just how easy to it is to deploy and interoperate). Put in specific test cases and have your folks consider this fact when they are looking at all new purchases. Here are some specific factors to consider:

Do you own your data or does the vendor?
Is the database structure and all data easily accessible to you without involving the vendor? If only your vendor can see the data, you’re locked in so be very wary.
Are the data formats that the system uses to communicate with other vendors open? If not, you don’t own your data.
How much of the technology stack is based on industry standards? The more proprietary the tech, the more you’re locked in.
Are all the programming APIs open, documented, and available without paying royalties or license costs? If not, when you try to get out you’ll pay dearly.

If you have other considerations, share them here.

McKinsey's view of Government 2.0

Shahid N. Shah — Mon, 27 Jul 2009 19:30:18 +0000

McKinsey & Company, the venerable management consultant firm, has a nice publication called McKinsey Quarterly. Along with Harvard Business Review and MIT Technology Review, McKinsey Quarterly is one of my favorite publications. Recently the McKinsey Public Sector folks published their E-Government 2.0 article (warning: login required, free article). Here's the summary:

Despite spending enormous amounts on Web-based initiatives, government agencies often fail to meet users’ needs online. By employing new governance models, investing in Web capabilities, and embracing user participation, agencies can raise the effectiveness of their online presence.

Some key paragraphs include:

During the Internet boom of the late 1990s, government entities raced to develop Web sites, and high levels of e-government spending became the norm. Spending on e-government-related initiatives has continued to grow—indeed, in 2009, the US government is expected to spend more than $71 billion on IT, of which an estimated 10 percent will be related to e-government.1

While the total price tag for e-government services has risen dramatically, these outlays have not yet delivered on the promise of e-government. Public enthusiasm for government Web sites has waned. Americans’ satisfaction with e-government, which rose steadily early in the decade, has started to decline.2 In 2004, Time featured three federal government sites in its list of the “50 coolest Web sites,” while more recent lists contain at most one mention.

Illustrating this trend, one US government agency site was recognized as an innovator in online information and transactions and became a model for other agencies to follow, as it enjoyed user adoption rates that justified its e-government expenditures. However, more recent initiatives have failed to catch on with users, who regard the Web site as having become harder to use and new services as too confusing and complex. Nor is this phenomenon confined to the United States. One government agency invested millions developing a service that enabled citizens to manage their accounts with the government online, only to achieve a disappointing adoption rate of less than 5 percent.

What’s more, data suggest that investments have not yielded major improvements in the operational efficiency of government. A random sample of six US government agencies suggests that administrative costs have increased by 7 to 12 percent per year over the past decade. Nor has public perception of government efficiency improved. According to the Pew Research Center, the percentage of US citizens who agree that “When something is run by the government, it is usually inefficient and wasteful” has increased in recent years, from 53 percent in 2002 to 62 percent in 2007.3

They go on to talk about how the government websites can improve through new governance models and improving web capabilities. It's a good article to check out.

New open source project management tool for large-scale enterprise systems

Shahid N. Shah — Wed, 22 Jul 2009 00:00:49 +0000

I just ran across the new Endeavour Software Project Management solution; it seems to be a pretty feature-packed web-based open source package to manage the creation of large-scale enterprise systems. Unlike most large project management solutions that assume waterfall approaches, Endeavour's designers understand that most modern applications are developed in an iterative and incremental development process and it supports agile processes by providing administration for software process artifacts, reports and collaboration among many different stakeholders. It's still quite rough around the edges but I think it's a great start.

Federated Vulnerability Management

Shahid N. Shah — Wed, 15 Jul 2009 14:49:45 +0000

The Guerilla CISO blog recently posted a very interesting proposal on Federated Vulnerability Management. I think it's a fantastic idea that should be seriously considered. If we use modern linked open data through some secure network channels I think we could make this happen without writing much code and getting all the agency data we need through RESTful mashup technologies. We wouldn't need any centralized servers and could really do it in a decentralized but fully federated and integrated way. For architects, the relevant paragraph from the posting was the following:

Security architecture models (FEA anyone?) that show federated patch and vulnerability management deployments as part of their standard configuration. OK with the firewall pictures and zones of trust, I understand what you’re saying, now give me patch and vulnerability management flows across all the zones so I can do the other 85% of my job.

A Radical New Approach to (MUTUAL) Authentication

Eashwar Ganapathy — Tue, 19 May 2009 16:57:01 +0000

[This thought paper is from Rel-ID Technologies Inc. - a Uniken venture]

Authors Sanjay Deshpande, Dr. Pat Shankar, Eashwar Ganapathy

Abstract In this article, we present a fundamentally new identity framework – RELATIVE IDENTITY - which addresses and eliminates many of the core problems faced by the current identity technologies. We postulate that authentication necessarily has to be mutual and that the only valid way to perform mutual authentication is to make fundamental changes to the identity representation framework.

This can be accomplished by –

Changing from end-point entity labeling (like in the case of login/password, biometric, digital certificates, 2-Way SSL and a combination of these) – to labeling the relationship between the end-point entities (which inherently covers the two end-points in its definition)
Making the authentication protocol truly mutual – and thereby eliminating the susceptibility to man-in-the-middle attacks and phishing

Identity and identification are central to any interaction, both in real and virtual (digital) systems. Especially where the interaction entails access to or manipulation of protected resource(s).

We firmly believe that any identity framework has to address the problem of establishing a mutually-authenticated secure connection BEFORE initiating any data transaction using that connection.

Introduction Identity and Authentication form the central building block of any information security solution/framework. Establishing identity using an authentication protocol is the starting point for any secure transaction. In order to be able to establish identity (be it man or machine), the entity must be characterized by a unique set of symbols (as per the adopted identity representation framework). During the process of actually identifying / authenticating the entity, the same characteristics of the entity are observed and matched against those that were captured earlier and associated with the entity.

The act of establishing identity is identification. Identity Systems must possess the capability represent, provide, maintain and establish identity. The identity representation framework must ensure that it is extremely difficult to compromise the individual identities it is used to represent. In this article we cover the following points:

Definition of RELative IDentity – the representation
Fundamental properties of identity (representation)
Proof that all authentication must necessarily be mutual ( that 1-way authentication basically flawed)
Fundamental properties of authentication / identification (the process of)
How is Relative Identity different from other identity schemes

The basic flaws and limitations in current identity technologies for websites prevalent in the World Wide Web SSL/Digital Certificates (when used for AUTHENTICATION) become apparent in the context of the axiomatic frame of reference defined in the following sections.

Definition of Relative Identity The relative identity of an entity is

Distributed among the relationship of this entity with other entities. Each such valid relationship –
- constitutes a unit “Relative Identity” – an important and inseparable constituent of the identities of each of the entities sharing a valid relationship
- contributes in the definition of the relative identity of each entity
- exists only in the context of two (or more) entities who share a relationship
Is the union/collection of all such “Relative Identities”
Is dynamic since new relationships may be established, while old relationships may be discarded, over time
Is associated with a set of labels/attributes/characteristics – immutable and mutable
- immutable - such as biometrics, which cannot be changed at will
- mutable - such as SSN which are awarded for a life time, log in passwords, bank account numbers which are changed quite often

In practical implementations of identity based transactions, one is concerned only with the specific (relevant) relative identity and associated attributes, and hence the rest of the identity representation is not susceptible to identity theft.

As is evident from the above definition, the concept of identity in the prevalent conventional identity systems that deal with only labels/attributes/characteristics – “What you have”, “What you know” and “What you are”, totally ignore the most relevant concept of “Who you know” – which is how humans establish trusted relationships.

Fundamental Properties of Relative Identity The unit relative-identity data -

must be unique (no two relative-identities should have the same identity data)
must be tamper-proof (difficult to reconstruct and reproduce)
must be secret - wholly / partially (should not be communicated in full form during authentication; should be known only to the related entities)
must be used simultaneously and uniquely, to identity all entities involved in the authentication transaction

Most of the prevalent conventional identity systems satisfy properties 1, 2 and 3 above. For example -

Login/Password would satisfy 1, 2 (partially) and 3 (partially)
Digital Certificates would satisfy 1, 2 and 3 (partially)

What is Mutual Authentication/Identification? Why does one need it?

As yourself the following questions -

what is the meaning of authentication if it is not mutual?
why would I allow someone to authenticate me, if I can't authenticate him/her?
would I produce my passport to identify myself to someone who does not (even seemingly) possess the requisite authority?
Even so, don't I run the risk of being duped into producing my passport to a person who only looks authentically like he/she has the requisite authority?

The basic flaw in identification over the internet is that an end-user assumes that the website challenging him/her for his/her credentials is indeed the authentic site – so long as interaction with the user-agent application (the web-browser) while accessing the website, is identical to previous such interactions. That is to say – so long as the website looks the same, behaves the same, and does not trigger a negative message from installed security products (due to more recent efforts in the anti-phishing features of these products).

All things considered, are you sure you can trust such a website that asks for your login credentials? Conclusion: Authentication, to be of any practical use, MUST BE MUTUAL

Fundamental properties of authentication / identification

The process for identification / authentication

must be tightly integrated with a given/underlying identity representation
must necessarily have a priori access to the identity data that is to be identified / authenticated
must necessarily authenticate all identifying/authenticating parties (entities) – preferably simultaneously

These are simple (minimal) properties that any identity/authentication system must possess. Some of them are straightforward while some may not be seem obvious.

Let us now visit some of the prevalent identification/authentication processes in light of the above properties -

Login/Password – satisfies 1 and 2 above
Digital Certifications/SSL – does not satisfy 2 and 3, and hence, should NOT be used for authentication
Hardware/Software Tokens (and OTPs) – satisfy 1 and 2 but do not satisfy 3

Please note that even the use of multi-factors satisfy only properties 1 and 2 and not the property 3

Let us look at the third property above for authentication protocols that essentially says that - the process MUST be mutual and simultaneous. The term mutual has earlier been defined in the context of client-server architecture as “client must authenticate the server and the server must authenticate the client”. Such a definition classifies any “1-way” authentication method executed twice as a valid 2-WAY or mutual authentication process. The fundamental flaws in existing mutual and 1-Way authentication systems are precisely due to the violation of properties (2) and (3) above. Mutual authentication cannot and should not be implemented using two 1-WAY authentication schemes – e.g. 2-Way SSL, or a combination of login/password and shared secrets/site-key. Any such scheme will be vulnerable to the same attacks that the 1-WAY equivalent is vulnerable to. For example, 2-WAY SSL is susceptible to MITM (man-in-the-middle) in exactly the same way that 1-WAY SSL is - for the same reasons.

How is Relative Identity different from other identity schemes?

Conventionally, identity is associated with the end-point entities (client or server) and authentication involved authenticating the end-points. Authenticating this information for both end-points in sequence is NOT secure mutual authentication – it is a concatenation of 2 instances of 1-WAY authentication.

The REL-ID (relative identity) approach to authentication is to identify and authenticate the ‘link/relationship’ between the end-point entities – not the individual end-points. That is to say – IDENTITY must necessarily be associated with the ‘link’ representing the relationship between the end-points. This is the only representation, and authentication thereof, that can legitimately be termed as MUTUAL – as the end-points are an integral part of the definition of any such representation.

Authenticating such a ‘link’ would necessarily be mutual – would ensure that all end-points are authenticated simultaneously, and makes the identity of every end-point relative to the other end-point(s) axiomatically.

Conventional Identity System

Relative-Identity System

We believe that, in order to (a) represent the above information correctly at the end-points and (b) arrive at the correct protocols for identification/authentication, one must develop the necessary mathematical frameworks and algorithms. However, before starting to derive them, one must accept and acknowledge the fundamental paradigm shift in the desired properties of such representations and algorithms.

The set of identity representations and identification/authentication algorithms constituting the REL-ID© Security Suite is one such implementation of the identity paradigm described here. Assuming that authentication must necessarily be mutual and simultaneous to be of any value, authentication schemes such as tokens, digital-certificates/SSL, login/password… cannot be compared with REL-ID – since they offer only 1-WAY authentication, at best. Furthermore, methods/products that claim to provide mutual authentication, but in reality implement two 1-WAY authentications (like SITE-KEY – flash-persistent object; Shared Secrets…), will remain vulnerable to man-in-the-middle attacks due to the inherent vulnerability in the conventional end-point identity representation scheme.

There are no known contemporary technologies/products that are built using mutual authentication protocols, which have the properties mentioned in this article, and which are available commercially.

2-WAY SSL == TWICE PHISHED

Eashwar Ganapathy — Mon, 18 May 2009 19:16:26 +0000

[This thought paper is from Rel-ID Technologies Inc. - a Uniken venture]

Authors Sanjay Deshpande, Dr. Pat Shankar, Eashwar Ganapathy

Basics of Identity and Authentication - In order to be able to identify / authenticate any entity (be it man or machine), the entity must be characterized by a unique set of symbols, as per the adopted representation scheme. During the process of actually identifying / authenticating the entity, these characteristics are observed and matched against those that were captured earlier and associated with the entity.

The act of establishing identity is identification. An Identity System must be able to represent, provide, maintain and establish identity. The identity representation framework must ensure that it is extremely difficult to compromise the individual identities it deals with. Identity and identification are central to any interaction, both in real and virtual (digital) systems, typically where the interaction entails access to or manipulation of protected resource(s).

For example, we are identified by our name, social security number, passport number, national ID card, fingerprint, voice print, DNA print etc. The context of identification determines the parameters used to determine the identity. While establishing our identity, one or more of these characteristics are elicited / captured from us, and matched against previously captured and stored characteristics.

Let’s take a look at prevalent IDENTITY TECHNOLOGIES

Login-Password The login-password is captured and stored A PRIORI with the server and then compared with the login-password that is presented before subsequent interactions with the login-password-secured system.
Biometrics (fingerprint/voice/DNA/iris-scan) The biometric is captured and stored A PRIORI and then compared with the biometric data that is presented before subsequent interactions with the biometric-secured system.
Photo-ID Cards After verifying that the Photo-ID Card is authentic using a system with a card-reader, the PHOTO on the ID-CARD is matched with the individuals face as well as the system-retrieved photo expected to be on the card.

Note that AUTHENTICATION NEEDS A PRIORI INFORMATION.

PKI, Digital Certificates, SSL and Authentication - PUBLIC KEY CRYPTOGRAPHY, aka Asymmetric Cryptography, is a form of cryptography in which the key used to encrypt a message differes from the key used to decrypt it; the user has a pair of keys - a public key and private key. The private key is kept secret, while the public key may be widely distributed. The keys are related mathematically, but the private key cannot be computationally derived from the public key in 'reasonable' time, and vice versa. Messages encrypted with the public key can only be decrypted with the corresponding private key and vice versa. Further, in conjunction with a signing algorithm and a signature-verification algorithm the key pair can be used to send verifiably signed messages

The two main branches of public key cryptography are -

Public Key Encryption - A message encrypted with a recipient's public key cannot be decrypted by anyone but the recipient (using his/her corresponding private key). This ensures confidentiality of messages thus encrypted. An analogy for public-key encryption is that of a locked mail slot. The mail slot is exposed and accessible to the public - its location (the postal address) is, in essence, the public key. Anyone who knows the location can go to the door and drop a message through the slot. However, only the person who possesses the key can open the mailbox and read the messages.
Digital Signatures - A signing algorithm, given a message and the private key, produces the signature. And a signature verification algorithm, given a message, its signature and the correct public key, can verify that the message has not been modified with since signing (generation of the signature). This ensures non-repudiation of the message thus sent. An analogy for digital signatures is the sealing of an envelope with a personal wax seal. The recipient checks that the seal is intact and corresponds to that of the sender, before opening the message.

A central problem in public-key cryptography is proving that a public key, which is publicly available, is authentic, and has not been tampered with, or replaced, by a malicious 3rd party. This problem is solved by using a Public Key Infrastructure (PKI), in which one or more 3rd parties, called Certificate Authorities (CA), certify ownership of key pairs. Another approach, used by PGP, is the 'web of trust' method to ensure authenticity of key pairs.

In PKI, a public key certificate (or digital certificate) is an electronic document which incorporates a digital signature to bind together a public key with an identity - information such as the name of a person or organization, their address... The certificate can be used to verify that a public key belongs to an entity. In practice this verification entails verifying that the digital signatures in the certificate were indeed generated using the correct private keys. In a typical PKI scheme, the signature is generated by a Certifying Authority (CA). In a web of trust scheme, the signature is either from the owner (a self-signed certificate) or another user ('endorsements'). In either case, the signatures on a certificate are attestations by the certificate signer that the information in the certificate and the public key belong together.

Why do websites face PHISHING attacks even after adopting DIGITAL CERTIFICATES and SSL technology? What exactly is wrong with DIGITAL CERTIFICATES?

In the 1990’s the DIGITAL CERTIFICATE technology was introduced by VERISIGN bundled with NETSCAPE. The idea was to issue certificates to entities requesting one from VERISIGN. This technology was based on the PKI scheme (made popular by RSA in the 1980’s). The term Certificate Authority was born and VERISIGN became the first such CA. Eventually other entities could become CAs by purchasing special certificates from VERISIGN or other CA’s and a CA chain came in to existence. The browser technology then invented by NETSCAPE incorporated the certificate technology and along with the SSL protocol became the de facto standard for SECURE INTERNET TRANSACTIONS. Since then this technology, that has been assumed to secure the internet transactions, went on to become a regulatory requirement for most institutions world-over.

Quite frequently, due to evolution, and at times mass acceptance of a technology, the industry seems to overlook some basic but extremely FUNDAMENTAL aspects of technology. Such ignorance (though unintentional) leads to serious security flaws – flaws that are exploited by fraudsters.

DIGITAL CERTIFICATES ARE VERIFIED NOT IDENTIFIED (or AUTHENTICATED) SINCE THERE IS NO DIRECT A PRIORI KNOWLEDGE ABOUT THE CERTIFICATE WITH THE VERIFYING PARTY / PROGRAM.

The Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) protocols use DIGITAL CERTIFICATES to establish a secure connection between a SERVER and a CLIENT. They are MEMORY-LESS protocols – they were designed to be so in order to make existing and newly developed web applications integrate with them seamlessly - for seamless interoperability. Both protocols are based on CERTIFICATE VERIFICATION. This proves to be a fundamental, subtle and yet non-trivial loophole when used for AUTHENTICATION – there is NO A PRIORI knowledge about the CLIENT or SERVER side certificates available at the verifying side of the connection, during the protocol exchange. A priori knowledge is a fundamental requirement for any AUTHENTICATION PROTOCOL, be it 1-WAY or 2-WAY.

Although the SERVER has a DIGITAL CERTIFICATE which is used to establish a secure SSL connection with the CLIENT – the CLIENT does not have any A PRIORI knowledge of this CERTIFICATE (public key). The SSL protocol only VERIFIES that the CERTIFICATE IS VALID and was issued by the valid CA (as per the contents of the certificate). The equivalent in real life would be to accept an ID card as valid simply because the card has not been tampered with – although the person carrying the card may not be the same person you are trying to authenticate.

Due to this flaw – any application can claim to be the “right or authentic” SERVER to a CLIENT as long as it has a VALID certificate - the same argument can be extended if one is using a CLIENT CERTIFICATE as well (in case of 2-WAY SSL). If 1-WAY SSL protocol is a VERIFICATION protocol – how can 2-WAY SSL protocol claim to eliminate the fundamental issues of AUTHENTICATION – since a 2-WAY SSL PROTOCOL is equivalent to 2 instances of the same 1-WAY SSL VERIFICATION PROTOCOL implemented on both CLIENT and SERVER side.

Have we missed something when it comes to using certificate technology as an identity system for IDENTIFYING WEBSITES?

As per the SSL Protocol, the client confirms that the CERTIFICATE produced by the server is VALID – that the contents of the certificate have not been tampered with, and that the domain name in the certificate indeed is the same as the domain name to which you are currently connected. That is to say, a CERTIFICATE can only be VERIFIED to the extent of the claims made on it – that it belongs to the ENTITY that has presented the CERTIFICATE. However, the client cannot confirm whether it is the SAME ENTITY that the USER is trying to connect to.

A fraudster gets a CERTIFICATE issued to himself/herself, with a domain name that sounds or looks similar, and presents the CERTIFICATE to the user – the SSL/HTTPS layer will NOT be able to tell you whether the USER is indeed connected to the website he/she wants to connect to. This loophole is not addressed and cannot be addressed in the way the DIGITAL CERTIFICATE TECHNOLOGY and SSL are implemented in the internet today.

Is it possible to correct the present system of DIGITAL CERTIFICATES?

No. Since it would mean a sea change in the entire process of creating, issuing, distributing and identifying the certificates.

If one has implemented the DIGITIAL CERTIFICATE Technology, does that mean their IDENTITY cannot be compromised?

Well, one can make their own educated judgment based on the arguments presented in this article.

According to us, ONCE the IDENTITY has been confirmed, the CERTIFICATE technology could be used to exchange encryption keys, and secure the transaction – IT SHOULD NOT BE USED TO ESTABLISH or AUTHENTICATE THE IDENTITY.

Why not?

The reason why DIGITAL CERTIFICATE TECHNOLOGY is what it is today is because of the fundamental nature of ‘online applications’. Digital Certificates themselves are tools to ensure that a given datum communicated from one end to the other is not tampered with and is ‘signed’ using the private secret corresponding to the publicly available ‘certificate’. The use of digital certificate technology between an all-purpose web-browser and any specific security-critical application can at best be described as a marriage of convenience – essentially because online applications came first!

Conclusions

The fundamental tenet of ‘securing’ any application is to uniquely, unambiguously and reliably identify the user of the application before authorizing and executing any action on the identified user’s behalf.
Furthermore, any centralized and fully automated ‘trust-building mechanism’ for capturing, storing and verifying the trust between ‘essentially anonymous entities’ across wide spectra of businesses and geographies will come with inherent weaknesses – they will be as secure as the weakest link in the security chain built around it.

Website Identity - the root cause for Internet Fraud

Eashwar Ganapathy — Thu, 14 May 2009 21:22:18 +0000

[This thought paper is from Rel-ID Technologies Inc. - a Uniken venture]

Authors Sanjay Deshpande, Dr. Pat Shankar, Eashwar Ganapathy

Abstract On the internet there are 2 types of websites - ones that take sensitive information from you and ones that don't. Online banking applications, shopping applications, stock-trading applications are examples of the former; while CNN, Google etc are examples of the latter. This article deals with the very real insecurities of working with applications of the former variety.

How do you know that you are at an authentic website? What if you are not? Authenticating a website implicitly assumes you already know what to look for in the website, in order to establish the websites identity - which in turn implicitly assumes you know what constitutes the identity of a website. Let us define WEBSITE IDENTITY to be a set of identifiers that can be authenticated to prove the identity of the website. Currently, there are only 3 identifiers that constitute WEBSITE IDENTITY - (1) URL, (2) CONTENT, and (3) SSL/TLS CERTIFICATE. Furthermore, let us note that - any kind of authentication of any identity mandatorily requires a priori knowledge of the identity information.

In this article we shall delve deeper into the above constituents of WEBSITE IDENTITY, and conclusively prove that they are fundamentally incomplete, leaving you - the internet-user, at the mercy of fraudsters who use this knowledge to their benefits, by sending fraudulent emails with links to similar looking websites.

The Website URL - when one sets up a website the first thing one does is to register the domain name (www.mywebsite.com) - that is the primary identifier for the website. More often than not, this is the ONLY identifier - for first-time visitors.

Let us say the website's domain name is communicated to you by the owner of the website directly/indirectly through trusted channels. In this case, since the identity information for the website has been communicated from a trusted source, the problem of authenticating the website reduces to authenticating the identifier - ensuring that the website you are visiting is authentic.

What if the website's domain name is communicated to you through channels that you cannot necessarily trust - the first question that arises is how would you know for sure that this identifier indeed belongs to the correct website.

For example, let us assume you are a customer of Bank of America. How would you know for sure that www.bankofamerica.com is the correct website if it has not been communicated to you by the bank? What if someone told you or you searched on the internet and got the website name to be www.boa.com instead, what would you do?

Do you know how to confirm the ownership of a given URL/Domain Name before using it? Further, even if the OWNER (let’s say the bank in this case) told you what to check (assuming there was a way to get this information) - if you have not received the information from a TRUSTED source, how do you verify that the information is correct?

NOTE that the DOMAIN REGISTRATION entities (companies that issue the domain name) do not verify the information provided by the individual who is registering the domain (website address).

NOTE that there is no central TRUSTED repository where you can find the WEBSITE NAME for a given OWNER. There are services like www.who.is – that give you information about who has registered the DOMAIN. However, since the domain registration entities do not authenticate or validate the owner of the website name – which means any one can register any name and own it – what use is this information anyway!

Website Content - Let us move on to the next identifier of the website – the content. Most users confirm the authenticity of the website based on just the visual cues and verifying the visual cues every time they visit the website.

The very nature of HTTP and HTML (the protocol and language used to retrieve and render website content, respectively) allows one to stream information/content from multiple sources. Which means, even if the visual cues are the same, how do you confirm the validity of the content - what if someone has tampered the content and/or it is being served from somewhere else? Further, if you are visiting the website for the first time – and the owner has NEVER communicated what the website should look like in the first place, how would you authenticate the website's content?

The website content – the HTML document - is available for any one to view, copy and save. It is a trivial task to scrape content off an authentic website (using a browser or wget or website copiers such as HTTrack etc), register a similar (but not identical) website, and put up the same content there - a COUNTERFEIT WEBSITE.

Let us say there are 2 URLs A and B that are displaying contents Ca and Cb - each implying that the website belongs to the same company X. If the company X has not communicated the correct URL(s) to its users - how would you confirm that the URL you are browsing (A/B) indeed belongs to the company X? If you conclude incorrectly, you could end up providing valuable information to a counterfeit / fraudulent website!

Digital Certificates - By far the most popular method of registering, certifying and verifying identity on internet.

The anti-trust laws in this part of the business world are laughable - to become a valid certification authority one just has to be affiliated to the company called VERISIGN directly or indirectly - isn't this a fundamental violation of the anti-trust laws? VERISIGN (www.verisign.com) is neither a government nor an international body.

If you navigate to www.patentoffice.nic.in, the official website of India's Patent Office and visit their e-filing section, most browsers say this could be a fraudulent website - because the certificate is not issued by VERISIGN or any of its affiliated certification authorities (it is issued by a company called NCODE SOLUTIONS - one of the valid root certificate authorities in India). Not just that, the address-bar turns RED.

Who decided that one has to trust VERISIGN? And why does that mean one has to trust all certification authorities certified by VERISIGN? Most consumers do not even know VERISIGN - MicroSoft, maybe, but not VERISIGN. In their defence - given the fundamental flaw with the Certification Authority scheme - there really was no solution but to pick up a bunch of 'root CAs' and declare them as the TRUSTED AUTHORITY.

An end-user has no A PRIORI knowledge of the certificate issued to an entity. The transaction (or act) of getting a certificate is a private transaction between the entity (for eg. a bank) and the CA (Certification Authority). This information is never distributed to the end-user and he/she in turn is in no way equipped to verify this information. How can a 3rd party (the CA) vouch for the authenticity of an entity to the end-user? Does it make sense for a child to ask a visitor (a stranger) to vouch for the authenticity of his/her mother? But that is what it is. Why is there a necessity for a 3rd party like VERISIGN (or its derivative CAs) to verify the identity between 2 parties who already share a primary relationship (like bank-customer or enterprise-employee ...)?

The original premise of the SSL protocol (that uses these certificates) was to establish an encrypted communication channel between two UNTRUSTED parties. What completely defies logic is - what good would an encrypted channel be between two UNTRUSTED parties?!

Banks and other e-commerce websites boldly declare that they are secure - they have SSL/TLS enabled websites. What good is it when the user does not know what to verify? He/She does not have a-priori knowledge of the information that should be present in the website's certificate - such as the signed content, the public-key in use etc.

The CA infrastructure and the current SSL protocol violate the basic principles of IDENTITY and AUTHENTICATION - that IDENTITY must be established first and then verified between 2 (now) trusted parties - using information shared during IDENTITY ESTABLISHMENT.

The above discussion conclusively proves that the three primary identifiers – WEBSITE URL, CONTENT and (optionally) PKI-based CERTIFICATES are incomplete as website identifiers. They leave the user at the mercy of fraudsters who use this knowledge to their benefit - sending fraudulent emails with links of similar looking counterfeit websites, luring the ignorant users to divulge sensitive information to the wrong websites.

Security Guidance for Critical Areas of Focus in Cloud Computing

Shahid N. Shah — Thu, 07 May 2009 17:50:55 +0000

The Cloud Security Alliance was recently formed to "promote the use of best practices for providing security assurance within Cloud Computing, and provide education on the uses of Cloud Computing to help secure all other forms of computing." Their first publication is out and is worth reviewing.

Publish at Scribd or explore others: Internet & Technolog Research security cloud