Archive for November, 2009|Monthly archive page
Takeaways from the CISO Roundtable
Filed under: Best Practice, Industry | Tags: enterprise risk, ERM, Industry, IT risk, risk, Risk Management
Leave a Comment 
Pravin Kothari
I hope everyone had a restful long weekend.
Two weeks ago while in Washington DC, I also attended a CISO Roundtable event we joint sponsored with Accenture. The topic was “A Risk Based Approach to Building a GRC and Security Program”. Distinguished speakers included:
- Bob West, Founder and CEO of Echelon One and former CISO at Fifth Third Bank
- Scott Charbo, Vice President at Accenture and former CIO at Department of Homeland Security
- Mark Lockareff, President and CEO of Agiliance
It was a lively discussion among CISO of various organizations. Bob led off talking about how risk is the new language the CISO must learn to speak to bridge the traditional communication gap between CISO and the other business CxO. Scott talked about how to effective measure risk in a large and complex organization. Scott introduced this intriguing concept of measure “flow”. Mark talked about how Continuous Assessment can take an organization from today’s compliance centric process to a risk based process in the future. Many interesting concepts were discussed and I will attempt to summarize some of the more thought provoking points in future blogs.
Some of the clear themes that came out of the discussion:
- Automation is no longer a nice-to-have: This theme from our Advisory Board was clearly echoed by the CISO Roundtable attendees. The CISO from a major federal agency commented that compliance burden for CIO and CISO is so heavy and increasing so, that if her department does not invest in GRC automation technology immediately, her organization will be unable to keep up with all the new compliance and risk management requirements that are still emerging.
- Being compliant is no longer sufficient: The CIO/CISO community has now clearly realized just being compliant is no longer enough. A paper exercise does the organization no good when it comes to managing risks and threats. The new mandate is all about continuous risk management. CISOs are asked to prioritize and concentrate their resources on highly critical assets. Risk management is a critical discipline in helping to set that priority.
- New risks are being introduced faster than ever: One of the main challenges these CISO face is to just keep up with the new risks and threats that are being introduced by new technologies and the ever more sophisticated evil minds. Mobile devices, P2P technologies, social media, more complex software, social engineering, fraud technologies are introducing new risks to the enterprise from every angle. Protecting sensitive data and privacy across all these channels of exposure is taxing. Just to understand and inventory what risk exposures are being introduced in a complex organization will require continuous monitoring technology.
It was great to see that the security leadership of attending organizations is very much at the leading edge in terms of understanding what the exposures are and what they must do to address these current and emergent threats. As always, whether awareness and understanding translates into effective execution is a whole different issue. If you don’t see the problem then you can’t address the problem. It’s good to see that at least the problem is well understood and has received high level of priority from the leadership community.
Takeaways from the Customer Advisory Board
Filed under: Best Practice, Industry | Tags: Agiliance, Industry
Leave a Comment Pravin Kothari
I just returned home from a week in Washington DC where we held a regional Customer Advisory Board meeting and a CISO Roundtable event.
It was great to spend time with some of our customers from up and down the east coast and even one all the way from Utah. Significant number of our customers from various industries including financials, healthcare, federal, Canada, etc. attended the meeting. We discussed our product roadmap and vision and received excellent validation and feedback. Most of the customers presented their deployments and success stories. It was also a great chance for the customers to hear about each other’s projects and discuss lessons learned. Kudos to our customer support and professional services teams, which earned universal high praise from our customers. Some high level feedback and observations from the Customer Advisory Board:
- Plan big but start small: All the customers had a great deployment strategy. They all bought Agiliance’s product because they had a vision of an enterprise GRC platform, a platform that can address all their GRC needs across the enterprise. However, they all had a very realistic deployment strategy. The key is to start with a very precise project with a very precise business benefit. Demonstrate value to the business and gain support for the tool, then broaden the usage. Many of the customers in attendance are on their second and third phase of deployment. Customers typically start with 1 to 2 of their use cases and then grow from there.
- No one can afford customization any more: The impact of this down economy is still very real. Everybody has less resource than before. Customer expectations have clearly changed. Customers want a product that works out of the box, that is easy to use, is easy to administer, and easy to upgrade. No one can justify large consulting bills year-in and year-out, even the large financial services and federal customers who have historically done a lot of customization to the products they buy. Customers want a product that works and not leave the main task as an exercise for them.
- Automation is no longer a nice-to-have: Compliance is still the number one driver for customer’s adoption of GRC technology. The burden of regulatory and contractual compliance is driving customers to automation. Everyone at the meeting agreed that there is no way their sizable organizations can maintain any resemblance of compliance without the help of technology. Resource and budget is just too limited vs. the responsibility they have to meet. Customers want to offload manual, repetitive and non-value-add work from their staff, improve efficiency and focus more on their business needs.
A big thank you to the customers who attended this Customer Advisory Board meeting and provided valuable feedback to help us continue to grow the product and company. I will summarize the key takeaways from the CISO Roundtable event once I get a chance to catch up from my week-long trip.
Is it Out-of-The-Box or Customized Application? Think Upgrade!
Filed under: Best Practice, Technology | Tags: Architecture, Framework
Comments (3) 
Pravin Kothari
Another way to determine if an application is OOTB or Pre-Assembled is to look into the upgrade history of the application. The biggest issue with Pre-Assembled applications is that they quickly turn into custom applications. As business requirements evolve, the customization usually gets more extensive. Why is this not necessarily a good thing? Customization is almost never supported by the vendors. At best, vendors will provide “best-effort” support for area of the application that has been customized. Ultimately, there is the inevitable upgrade challenge. Attempt to upgrade a customized application more often than not turns into a complete redeployment. Redeployment is obviously time consuming and expensive. As I have said many times now, as long as that is a trade-off that is understood upfront and is a desired trade-off, then there is nothing wrong with selecting a RDP based application. Too often, we see companies unknowingly go down the customization path and be surprised with the effort and cost associated with such a strategy.
A customized application is expensive to the customer, and can be equally expensive to the vendor. Patching, new feature design, platform certification all become exponentially more difficult as the engineering team now has to account for more variations and unknowns in the install base. The fact that customers cannot upgrade easily, usually results in the vendor supporting many different versions of the product. Even very old versions still need to be maintained because it is required by important customers. There are numerous stories in the software industry about vendors struggling to support legacy products because all the engineers that worked on the legacy code had left the company. New engineers support the product by reverse engineering the legacy code. The solution to this problem is usually to ask the customer to buy more consulting services or premium support.
Upgrading a customized application can involve dealing with any of the following, ranked in increasing order of difficulty:
- Manual apply the upgrade and migrate your data because vendor’s upgrade tool is not compatible with the customization.
- Re-apply all customizations after automated or manual upgrade
- Update customization due to changes in data schema
- Update customization due to changes to API
- Update customization due to changes in product behavior
- Update customization for past workarounds when new features are introduced
- Update customization that uses undocumented API
- Difference between new vendor code and custom code to figure out what has changed and merge customization into new vendor code
If you are looking for a OOTB product, then you should ask deeper questions about upgradability during the product selection process. The answers will help you calculate the total cost of ownership over the long run. Ask the vendors and check with customers who have been using the product for at least 2 years and have done at least one major version upgrade. Some questions to ask:
- How many different versions of the product are in use? A true OOTB application should have no more than 2 major releases, each with a couple of minor releases still in production.
- How long does a typical upgrade project last? Is it a few days or weeks, or is it more like 3 to 6 months or even longer?
- What percentage of customers use the latest major release? It should be over 50% six months after a major release.
- What percentage of customers has successfully upgraded without using paid services?
One lame response you will often hear from vendors when justifying why their upgrade statistics are less than stellar is that while their software is easy to upgrade, some customers just do not want to upgrade. Every customer I have ever met, especially for emerging market such as GRC, wanted to upgrade to the latest version in a timely manner. Customers who put off upgrading for a long time do it for a simple reason: the pain of upgrading outweighs the pain of living with old software. It’s as simple as that.
