All about IT Governance

There are a few deployment strategies and would depend on the ’status’ of your IT applications and ‘posture’ of the current DR deployment (if any).

I will describe the status and posture later but lets assume that most of our Business Applications are deployed (and not being built/delivered) - then, one of the deployment strategies we have seen is: Start a DR site with ‘DR ecosystem’ and ‘Testing/Staging ecosystem’ in the same datacenter.  As you build the DR ecosystem, you can test failovers on testing/staging ecosystem with DR ecosystem. On reaching sufficient comfort, start fail-overs between primary-to-DR site. Treat this as a baseline and any additions, you first test between DR ecosystem and test ecosystem and finally test with primary site. This is a great strategy as long as your IT ecosystem is fairly stable.

The assumption made above is what I call ’status’ - term refered to status of the business applications - IT is always deploying upgrades one way or another - its hard to see a ’stable’ status.

In addition to the status, you could also have a ‘temporary’ DR site and that is what I call ‘posture’ - term used to refer to DR ecosystem status. In the above scenario, the posture of the DR site is completely new.

Now back to another example, if the status of IT is half-ready and DR posture is ‘temporary’, it might be best to do this:  Start creating a clone of the existing temporary DR site (assuming it is deployed right) at the new site - start migrating application by application to the new site. Essentially, you are doing DR-to-DR site migration and performing fail-over between these 2 sites. This would also enable you to not dump all the investments in the old DR site. While you are doing this, new deployments should be done in the new IT ecosystem and perform fail-over tests between the primary and new DR site. Once the old DR site is ready to be retired, start the fail-over testing between new DR site and the primary site.  Whoooosh!

If the IT status is pretty stable and posture is fully ready however you need a new DR site for logistics reason (which is very rare), you may want to consider building a DR site (which is almost or better clone of the old DR site) and perform Primary-to-New-DR-failovers and build this one application at a time.

If you need additional perspectives, please let me know. Maybe, I can help.

What is the bare minimal risks that your ITGC SOX controls should cover? Although there are ITGI/COBIT documents to guide you through, one can easily get lost in the maze - I thought, I will put together this checklist for anybody to apply this to get a comfort. 

a. New accounts or modifications to account privileges are approved - OS, DB, App, Network, Logical Security (VPN, ActiveDirectory, NIS, LDAP and other authentication sources),  Physical security.

b. Terminations are performed timely - applicable to same processes as above

c. Transfers are handled as combination of b. and a. above - applicable to same processes as a.

d. Controls around change management to specifically address database object level changes, data fixes, data migrations and UATs are recorded for all application level changes

e.  Shared privilege level account management - passwords are changed when team members having access to shared privileged accounts leave the company - applicable to all areas listed in a.

f. Storage backup is tested for recovery (especially for databases)

g. Password configuration complies with enterprise standards for areas listed in a.

Optional:

a.  Account reviews in each area listed in a.

That would depend on how you deploy it.

With the right set of policy and deployment standards, the cost can be zeroed right from the initial days of deployment and you need to strike a balance between the risk vs. the benefit - benefit as in agile environment, risk as in exposure to security threats.

For example one of the policy could be:

No sharing of virtualized zones between business applications. Say, ERP and HR applications.

With this, you reduce the security exposures and leverage existing set of controls (assuming existing controls are strong). However, here is where you strike a balance between risk vs. benefit. You lose a bit of agility of virtualization however it is well worth it.

Another policy could be:

All changes to the virtualized zones/clusters align with the existing change processes with appropriate approvals including access changes. Again, assuming there is a strong change process and security related changes are well addressed.

This would help increase awareness and reduce the ‘knee jerk’ reaction to make changes to virtualized zones.

Another policy could be:

Migration to production (regardless of OS, Database, Applications, interfaces, Network connectivity, storage changes) complies with Security checklist - this checklist ensures securing the base operating system (hardening), physical and logical access to console, admin access to each zones and so on for each associated layers.

Another policy could be:

Logs of changes are maintained in the system (global zone and virutal zone) and is audited periodically.

This is to ensure that potential exposures are detected and addressed.

Overall, in a typical public company, almost all of the above controls would exist (existence is one thing, execution is another) excepting the last audit of logs control.

Here is an interesting conversation that started me to write this blog by Christofer Hoff at http://rationalsecurity.typepad.com/blog/2008/05/virtualizing-se.html

He has raised several key points of which one of them is SOD - I agree with his concerns on SOD and with a strong policy and procedures, it can be addressed and is not impossible.

As business evolves through standard growth, mergers or acquisitions, organization could find itself trying to manage and maintain multiple, redundant data centers.

The agenda for Data Center Consolidation (DCC) could be to

• centralize your systems,
• Reduce power and cooling costs and protect your environment by implementing comprehensive security
• business continuity and availability plans.
• Eliminate IT redundancies
• Increase IT asset utilization
• Reduce management and operational costs
• Achieve greater return on investments

Typically DCC projects is sponsored by core-IT management. DCC projects are run as a program than a project as it involves cross-IT and business owners accross.

Every DCC program has many unique challenges. Hence getting the scope of the DCC should be defined and agreed-upon. Also identifying and obtaining sign-off to what is not done is equally important. A top level presenattion to the management about - Basics (What we do and what we dont do, Strategies followed, High level steps in moving), Process, Budget and time line should be able to help management understand clearly the direction and would help them approve the budget.

Click here to see a presentation of DCC run as a program