Archive for the ‘Best Practice’ Category
Bridging The Conversation Gap
Pravin Kothari
Accenture and Agiliance’s CISO Roundtable event had some very interesting discussions and presentations. Bob West, CEO of Echelon One and former CISO at Fifth Third Bank led a discussion about how to bridge the conversation gap between CISO and the other CxO. Here are some of the key points presented and discussed:
CISOs typically have their own vocabulary which doesn’t translate well when speaking with other members of the executive team. CISOs talks in terms of protection of assets and data, prevention, confidentiality, integrity and availability. CEOs and CFOs talk about business value and how their investments relate to top and bottom line growth. The result of this language gap is that most CEOs and CFOs do not fully appreciate the work of the security organization and value of security technology investments. Security is almost always viewed as a cost center. Since the value of security is not clearly understood by the board, CISO’s budget is traditionally a small portion of the CIO’s spent.
For CISOs to be effective in their roles, they need to translate security speak into business speak. This means security must be framed into the two things that business understands and measures: performance vs. risk. A similar role for a CISO to model after is that of the General Counsel. Just like the General Council advises the board on legal risks and enable the business to pursue projects with legal coverage, CISO needs to come to the table as business partners and counsel the business on what security risks are acceptable and how that trades off against performance. This means CISOs must be able to measure and present security investments in terms of risk. Emerging IT GRC solutions should be considered to bridge this gap.
All other parts of an organization are measured on their performance, yet CISO and the security organization for the most part still behave as if security is black magic. A question was posed to the CISOs in attendance on how do they decide on:
- What security technology to invest in?
- How to compare competing technology alternatives?
- How much security is required and how much is enough?
The unanimous response was the CISO relied on their technical team’s qualitative justifications. Measurements such as risk are rarely used to quantify the benefit of the security investment. The participants also reluctantly agreed that this lack of quantitative measurement also leads to “fad driven” purchases, where the trendiness of a new technology and the technical team’s enthusiasm for that new technology often have too much contribution in the decision process. Pick any point in time in the last 20 years, there is always a cool new technology of the moment that is the best thing since sliced bread.
Mature security organizations need to have clear metrics to help the executive team understand whether they are performing effectively or not. Business is about the tradeoff between performance and risk, the security profession should be no exception. Any security technology investment either has to reduce risks or improve the performance of the organization. Otherwise, the organization should have no reason to invest in that technology. Once a CISO can quantity what the security team does and how security investments translates into risk reduction or performance improvement, then the CISO’s team is no longer viewed as a simple cost center.
Of course this is not a trivial task and few CISOs have done this successfully. Fortunately one of the CISOs in attendance, an Agiliance customer, has actually been able to achieve this and shared his story with the group. This CISO is from a defense contractor that operates communication infrastructure for multiple branches of the military. This CISO has deployed Agiliance IT GRC technology to measure the risk and compliance (to contract terms) level of their outsource operations. Today he presents regular reports and is in the process of providing real-time risk and compliance dashboards to his clients at the Department of Defense. The contractor is now actively selling this real-time risk and compliance capabilities as a differentiator when they bid on additional military contracts. The real time visibility of risk is of great value to the DoD organizations and have been instrumental in landing large contracts. This is a great case study of how a CISO has successfully articulated and positioned security and GRC technologies as a business enabler that helps to increase revenue performance and reduce revenue risk.
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.
Is it Out-of-The-Box or Pre-Assembled? Try before you buy!
Filed under: Best Practice, Industry | Tags: Architecture, business
Leave a Comment Pravin Kothari
I hope I made it clear in my last blog the difference between true OOTB and Pre-Assembled applications, which often require development to meet your needs. Sometime it is very difficult for a customer to tell the difference during the product selection process. Applications requiring customization can be made to look very slick, like a movie trailer. It’s amazing what a good sales engineer can do – they are not any less skilled than Hollywood artists. 
So how can you determine if a vendor is selling OOTB or Pre-Assembled application? The easiest way is to just go with an authoritative source if available. In the IT GRC space, take a look at reports like Gartner’s MarketScope for IT-GRCM. If you want more details, place an inquiry call with the analysts that wrote the research. In Gartner’s case, you would want to talk to Paul Proctor. Remember that analysts like Gartner will never outright endorse a vendor for a number of reasons, however, they can help you determine what type of technology is best for you, whether OOTB or something else. They can also tell you which vendor is really in which category. As part of their research, they talk to many customers who have actually used the products and can give you examples supporting their recommendations. If you have access to these analysts, you should not hesitate to request for an inquiry call.
The most bullet-proof way to validate this is to get your hands on the product. There are many different ways you can do this as well. Proof-of concept (POC) is a popular way. In a POC the customer gives vendors use cases and ask them to come back and show that the tools can meet the use cases. It is debatable how useful is a POC if a vendor is willing to invest in building customization for the POC and represent it as standard product functionality. Another approach is a Sand Box. This requires a vendor to provide an environment to the customer where they can play with the software without the vendor looking over their shoulder. This can be effective if it is done correctly. There are two wrong ways to do this. If you give a vendor detailed use case and other data so they can provide you a custom sand box, then you are not that better off than just a POC. If you just ask for the generic product and play with it without any training, you will likely get frustrated and not be able to explore some of the more advanced functions. Anything you can use without any training probably doesn’t have enough flexibility to meet your needs. The recommended way of doing this is to go through the vendor’s standard training course and ask for a generic evaluation copy for two weeks. Go through a fruit-fly version of the deployment experience on your own and see what exactly is OOTB. Allow a vendor to hold your hands along the way and even make recommendations on how to do things, but don’t let them do anything for you. Some people call this the “touchless POC”. You may have to pay to attend the training and you will have to have technical resource available to support this, but it’s a pretty small price to pay if you see how much effort some customers put into their RFP and POC processes.
Another good acid test is to look into upgradability of the product. We’ll discuss that next time.
Earl Perkins of Gartner Talks About Justifying Security Projects
Filed under: Best Practice, Industry | Tags: business, compliance, enterprise risk, Gartner, risk, Risk Management
Leave a Comment Pravin Kothari
Early Perkins of Gartner wrote a blog yesterday about the challenges of building business justification for identity management products (you can just broaden the whole discussion to security technologies in general). In his point #3 he pointed out that if security folks want to be invited to the Big-Boy table, they need to link security to justifications that business understands, such business risk, compliance and business process improvement. Make sure you read the response from Ed King, one of our resident identity management geeks here at Agiliance. He built on Earl’s thoughts a bit further and offered some concrete examples of risks that can be measured and provided as business justifications for security technologies.
BMC Viewpoint’s Special Issue on IT GRC
Filed under: Annoucements, Best Practice | Tags: compliance, risk
Leave a Comment Pravin Kothari
BMC’ Viewpoint magazine’s latest issue is all about IT GRC. It has some interesting articles from contributors inside and outside of BMC. I wrote an article titled “The Big Picture: Beyond Compliance to Risk Management”. You can check it out by request a free copy from BMC here: BMC Viewpoint
Risk Mitigation and Remediation Automation – Let’s Not Reinvent The Wheel
Filed under: Best Practice, Technology | Tags: Assessment, Automation, mitigation, remediation
Leave a Comment Pravin Kothari
We’re finally at the end of this discussion on defining GRC automation. We discussed mitigation as part of the process automation earlier.
Risk mitigation and remediation are not only an integral part, but also usually the most expensive part of a GRC program as it requires changes in your environment. Some of these changes may require new processes and even additional people if the process is not automated. Automation of GRC processes is still relatively new to most companies. Most companies are still working on front-end process automation. More mature organizations have started working on back-end automation for mitigation and remediation of issues. The cost savings from automating the back-end processes can be very significant.
When the risk, gaps and issues have been identified and prioritized, a response is needed to mitigate the risk , this can include requesting an exception, accepting the risk, transferring the risk, providing compensating controls, launching a campaign, etc. Some of these mitigation actions, e.g. requesting an exception, can trigger their own automated processes. Remediation is one of the possible mitigation actions.
Remediation actions can be manual, partially automated or fully automated. Partially automated remediation actions have some parts accomplished with integration and other parts manually executed. For example, automating ticket integration with Remedy, where appropriate user makes the changes by hand. The technology here is integration to the help desk of your choice. Not a trivial task, but not rocket science either.
Certain remediation can be fully automated and it typically involves integration with some sort of management software. System management software, or the new fancier term “business service automation (BSA)” can apply patches, make configuration or policy changes directly to applications, servers, network and telephony hardware. These applications are the bread and butter of datacenter operations team. Security software such as identity management, secured configuration management, data leakage prevention are able to implement access changes via remote requests as well. Identity management can even reach into ERP applications and implement segregation of duties controls on business transactions. These are the tools of trade for security operations team. There are a number of new and old technologies that fall into these two categories of system management and security tools, and there is no sense for me to inventory these on this blog. What is important to note is that these technologies do not fall under the “GRC” management space. Remember that GRC (capitalized) is a well defined application category, where as “governance, risk and compliance” is used loosely to describe a whole slew of technology solutions that have something to do with compliance and risk…. [The abuse of the term GRC by vendors is a whole topic of its own. I’ll reserve that for venting some other day J] System management and security management software are necessary in their own right, solving operational and compliance problems. The key is for GRC applications to leverage these existing assets and not try to re-invent the wheel by duplicating capabilities already available in the infrastructure.
Whew! That was a long discussion, longer than I expected, actually. I hope you found this thread on GRC automation definition useful.
Privacy Humor: Google’s Opt-Out Village
Pravin Kothari
A little GRC fun. An alternative for total privacy protection. Enjoy
Control Automation
Pravin Kothari
Process automation is a critical component of GRC automation, but it’s only 1/3 of the whole story. The other 2 are Control Automation and Remediation Automation. Process automation is all about making people work together more efficiently and ensure processes are followed and procedural controls are enforced. Process automation does not address the issue that a lot of these manual tasks such as filling out surveys and calculating risk scores can all be automated from data already available from their environment. These are data already being collected and analyzed by the vulnerability scanners, configuration checkers, log management, identity management, database security, and host of other technologies. Most companies have invested millions of dollars into these control technologies, but when it comes to GRC automation, companies still send control questionnaires in spreadsheets or surveys to the business owners, application owners and security teams to fill out manually.
Control automation tries to leverage this readily available data to automate the control testing and evidence collection process, so people can be relieved of the tedious and repetitive tasks and focus on more important tasks that require human judgment and rationalization. Control automation improves data quality and reliability as manual processes are error prone and subjective. Control automation also makes it practical for a company to increases coverage in terms of both covered assets and expanded sample size. Lastly, control automation also improves data availability as the data is instantly pulled without manual steps, enables sharing/reuse for multiple requirements, and reduces the time and cost of compliance. Control automation is strategic because it is a key enabling technology to achieve closed-loop, continuous, risk-based GRC processes with lower cost, the holy grail of GRC.
Today most company’s GRC processes are compliance driven and periodic in nature. This is the first phase of maturity for a GRC program. A periodic process takes snapshots in time to satisfy compliance requirement, but provides no visibility on compliance issues between audit points. More and more companies are seeing the deficiency of this compliance focused approach impacting their business in negative ways, as they get exposed even after passing say a PCI audit. Risk is persistent and risk does not cease to exist between audit points. A true risk based process requires continuous monitoring of the critical controls, threats and vulnerabilities with automated evidence collection and controls testing. When a control deficiency or vulnerability causes a risk to increase, that risk needs to be assessed and mitigated according to criticality and severity. In a risk centric and continuous process people’s time and energy are spent on managing exceptions, not performing manual data collection and processing tasks. Compliance then becomes simply a branch process that takes a snap-shot-in-time from this continuous flow of data for documentation and audit purpose. The picture below attempts to illustrate what a continuous, risk centric process looks like and where human involvement is concentrated.
From the above picture we can define control automation as the automation of the following task:
- Collect and transform source data
- Map collected data to controls that need to be tested
- Test the controls and attach evidences
- Translate test result and map to compliance and risk requirements
- Compute compliance and risk metrics
- Monitor and raise alerts based on rules and thresholds
- Prioritize issues and alerts to facilitate human analysis
Next we’ll take a look at each of these components in more detail and talk about best practice for adopting control automation.
