Regardless of a company's size, how it manages employee turnover, staff mobility and increased use of consultants and contractors

are causes for concern by auditors in terms of how user access rights are handled. Despite overburdened IT and human resources departments, companies need to ensure controls are in place to keep their networks secure from current employees, as well as terminated ones. Whether it's for a Sarbanes-Oxley Act audit or an IT risk assessment, determining access to a corporate network containing digital assets and intellectual property should be a high priority More often than not, however, user access gets the attention it needs only after a breach or act of fraud. By implementing some solid user access policies and procedures, companies can minimize their exposure to security breaches. Auditors should start by asking corporate managers to produce lists of current employees, employees terminated since the start of the year and users who have been denied access; policies and procedures that govern the granting of user access and file-sharing privileges; and the process for granting new access rights when employees move to different positions. They also need to know what review process is in place to verify that each user needs his or her current privileges, as well as the company's termination procedure. When checking a random sampling of terminated employees against users who have been denied access, auditors can determine how effective controls are at disabling old accounts. Frequently they find that employees who left a company five years ago still have full privileges, including e-mail, Internet and VPN access, as well as use of company-paid cell phones. Another concern is when employees move up in rank but retain their old access rights, which may allow, for example, an employee to create false vendor accounts or approve payment for his own invoices. Is the role of auditors simply to audit? That depends on their company, but what makes them more valuable is their ability to address best practices on how to minimize lax useraccess privileges. My favorite solution is to create a "passport" that HR assigns to every employee containing that employee's job description, department, manager, access rights and file-sharing privileges. Ideally, each job description should have a predefined template including this information. As an employee moves vertically or horizontally in the company, the new position should have its own passport, and each employee should be allowed only one passport. This prevents employees from retaining unnecessary access. HR should have an exit interview with all employees leaving the company to collect keys, pagers and cell phones, and provide legal documents that require signatures. At that time HR should send an e-mail to all groups responsible for terminating benefits and physical, IT and telecom access. Taking action today should minimize the potential for fraud and negative media attention.

As the rapid adoption of service-oriented architecture continues within the corporate environment, companies are realizing that implementation is not instantaneous but evolutionaryTo accommodate this process, a simplified SOA reference architecture has evolved that seems to embrace all corporate industry and vendor variants. Fundamental to this reference model are the logical partitioning and separation of all corporate/IT functionality into a set of common services, logically interconnected for shared use by a common enterprise service bus (ESB).

At the top of the reference architecture are the crown jewels of the corporation: corporate business services. Underpinning the reference architecture is the physical world's delivery vehicle interface: infrastructure services. The architecture's three support pillars are development services, management services and security services. Logically partitioned business process services, information services, collaboration services, business partner services, business application services and asset access services form its core. The base for the architecture is the physical infrastructure of clients, servers, storage and networks. The tuning of the reference architecture from its origins is the result of a shift in corporate priorities. Based on corporate CEO comments in 2006, cost reduction is the pervasive issue, but three additional priorities have surfaced: expansion, enhancement and extension of the ability to collaborate internally and externally; creative innovation of business models and processes; and business optimization leveraging new and existing information. CIOs in 2006 also added two IT priorities to their list: any-to-any connectivity and resource/asset reuse. These five priorities have become the focal points for SOA implementation. From the concept of a single SOA reference model, specific subarchitectures, such as service-oriented management and information architectures, have evolved. In reality an SOA subarchitecture is required for each enabling services type. The most complex of these is for infrastructure services - a separate subarchitecture is required for each of the four forms of physical infrastructure. Cisco had it right, but only as far as the name - service-oriented network architecture (SONA). By not originally linking SONA directly onto the SOA reference architecture and identifying it as an open, evolutionary subarchitecture, Cisco and the network industry went out of sync with their IT counterparts and corporate customers. The evolution of the ESB also is a work in progress.The ESB.being logical in implementation, may be common (shared) or composed of separate buses for each services type-a management bus for management services, a process bus for all process services and so on.As more corporate SOA implementations occur, the need for physical as well as logical separation of buses may arise. While the influence and adoption of SOA is unquestioned within the corporate realm, numerous architectural questions remain unanswered. Should virtualization be a common services type similar to access? Can management and security services be combined into a single set of management services, such as in IBM's SOA reference architecture, or do they need to be distinct and separate? Are governance and compliance services part of management services, or are they separate SOA core services? Will reuse of business, as well as application, components ever become reality? How does telemetry information, such as RFID and other forms of sensors, fit within access and security services in an SOA? Is a separate and distinct event bus required as part of the ESB subarchitecture? Although voice is being incorporated within SOA, where and how does video fit into the architecture? Web 2.0 standards and technology have become part of SOA; will Web 3.0 also be embraced? Last but definitely not least, will Cisco or another vendor create a SONA that embraces all of the SOA services requirements in such a manner that it can be established as a viable networking subarchitecture? Stay tuned.