Archive for April, 2008

MSP - pain or benefit?

Tuesday, April 15th, 2008

MSP - new glorified keyword for ‘outsource vendors’ - Managed Service Providers.

MSP is glorified because, gone are those days where your project/program managers, Business Analysts, DBAs help run the Oracle ERP implementation while the rest of the team are all outsourced engineers.

Today, MSP is about giving an outsource vendor full responsibility of delivery - Design, Develop, Test. You build the requirements & delivery program while your production team will simply inherit the applications built to the your standards and to match the business requirements.

However there are inherent risks with this - Resource risks. People granted access to privileged accounts as part of MSP task needs to be terminated as soon the MSP employees leaves the company - the risk is, your confidential or sensitive data could be put in somebody’s hands who cannot be directly controlled by you. If you add culture difference between the companies and the country where the development is being performed, it is hard to not consider the risk.

However, by developing trust while meeting as frequent as once per week to understand who accesses have to be disabled would help reduce the MSP risk to a minimal.

Governance without Program Management

Tuesday, April 15th, 2008

I remember somebody asking me, why is there such a big fuss about program management - why is it so important?

Here is my response: Lets say, I have diabetis and I would like to lead a structured and sustainable life - exercise every day, eat small portions and more often, take medications,  avoid bruises etc. The keywords ‘Sustainable’ and ‘Structured’ is what makes a set of tasks ‘Program’.

The program should have objectives, plans, timelines and should be measurable.  Example Programs would be SOX program, DR Program, Outsource Management Program, IT Service delivery program etc.

What makes these a program? They all require a methodology to ’sustain’ the tasks/processes involved.

What part of DR is expensive?

Monday, April 14th, 2008

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.

Security vulnerabilties in SW - Should we worry?

Friday, April 4th, 2008

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.