All about IT Governance

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

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.

IT Forensics tools today can be categorized into Data gathering and data analysis.

 The data gathering tools runs a monitor on the subject machine and gathers the necessary information - typically a mdf or pst file in windows environment.

The data analysis tools are evolving and would depend on the legal objective - if the objective is a simple source code search or keywords, it is quite easy. However, if you are looking for photographs or audio or video, it is complex - luckily, most of the legal needs today are ‘text’ based lookups.

One of the key areas where the tools offer an extra hand is: they record the system name and date which are very important to prove it in a court of law.