All about IT Governance

For those who are not following  Symantec in the past 6 months, you may be in for a surprise that EDS was the appointed outsource vendor for taking over most portions of the IT. Although, the details are a bit sketchy, it is our belief that a minimal IT is being owned by Symantec and the rest of IT services including client services, help desk services, infrastructure management and core business applications management is handed out to EDI.

The following are the lessons we have gathered:

a. There are 3 schools of outsourcing:

1. Outsource business secondary services (helpdesk, client services etc.)

2. Outsource a portion of your growth services (Internal QA, Internal Development for IT)

3. Full-outsource: Outsource everything except Governance (including IT Security), Compliance and Vendor Management

We believe what has hapenned at Symantec is #3 above. It is a fairly large responsibility however, it is very common in Hospital environment.

b. Symantec & EDS are now in a wedlock - it is hard to even imagine looking back

c. We strongly believe, if the company is in either Run or Grow mode (not transform mode), then ‘full-outsource’ may work.

d. EDS does not come cheap however, if Symantec strongly believes in ‘Grow’ mode, maybe IT was a distraction (I know, I can’t believe I am saying it).

e. Company employees would have to be transitioned in various packages however, it may be hard to build a team ever again to build out IT - so skeletal team within above areas and ‘hard to find’ liaison people would have to be retained.

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.

Simple answer: Data recovery.

Detailed answer: It would depend on your RPO expectations and data storage/retrieval strategy. If the data is mirrored (in real-time or almost real-time using NAS/SAN), it turns out to be expensive but RPO can be low. However, if the data is stored on tapes, it would be cheaper however, RPO would be high.

Companies like NetApp are  a key element for the first approach (Data mirroring approach) while Companies like SunGard are key players for the second approach.

I was speaking to a VP of IT of a financial institution in the San Francisco bay area to understand what keeps him up at nights - Two issues - Security vulnerabilities of financial SW that was developed in-house  & some of them that they have installed several years ago. And the other issue was telcom applications. The telcom applications support is slowly outsourced to MSP so he was not concerned on a long term.

Security vulnerabilities in SW can be used as a vehicle to expose the privacy and data. Vulnerabilities from inadequately designed or written code create opportunities for attackers to threaten privacy and steal data.

The major vulnerabilities that is taking a lot of attention these days are:

Buffer Overflow

Cross-Site Scripting

Parameter Manipulation

SQL Injection

Tools from companies such as Coverity (SWAT), Fortify (360), Ounce, etc help detect the Security vulnerabilities and eliminate in the place they reside : in the source code itself.

Which applications should an organization be concerned about?
Security vulnerabilities can exist in virtually any application accessible via the Internet or other networks. Web applications provide a popular avenue for delivering information and services, which makes them attractive targets for attack. These applications can contain security vulnerabilities that, unless identified by some reliable means, can remain undetected until an exploit is discovered and the damage has been done.

Newer SW development tools along with coding SW applications with Security in perspective (adequate checks and closing doors for any threats such as crosss-site scripting) would make more robust SW leading to reduced threats and hence exposures. But these software wou;ld interface with legacy SW applications and thats where my new connection (VP) was expressing his top most challenge that he is facing now.

What are the most common application vulnerabilities that could compromise the information security?

The most common application security vulnerabilities fall into two categories:

• coding errors and
• design flaws.

Coding errors are programming flaws related to input validation, unbounded parameters and encoding, and they include:

• Unvalidated sources of input
• Use of unvalidated input
• Unvalidated output streams

Design flaws could include the following issues not implemented appropriately:

• Flawed authorization and access control - Access control and authorization would
• Flawed authorization and session management
• Native code and buffer overflows
• Dynamic code
• Weak encryption
• Application configuration
• Denial of service
• Network communications - Network communications btw applications, one feeding fake data and the other not validating for fake data can mislead the design, and design based on this data could end up as a fraud - somebody on the other end could be data-diddling for all you know.
• Unsupported application interfaces - Connecting to/from an interface that has not implemented security measures to overcome compromise of information security can be a nightmare as the interface cannot be brought down instantly and even if the measures are taken at the receiving end, it costs a lot of processing power at the receiving end to detect, process and respond back with a error code for each data instance. So, data interface should be treated with utmost importance whenever interfacing with a legacy applications that known to have none/weak in security design.
• Improper administrative and exception handling

So,….. What would you recommend to strengthen the security for legacy applications? I will write in the next blog.