Archive for the ‘Industry’ Category
Manage Risk by Measuring “Flow”
Filed under: Best Practice, Industry | Tags: Risk Management, Security
Leave a Comment 
Pravin Kothari
Last blog I summarized some of the key points from Bob West’s session at the Accenture and Agiliance’s CISO Roundtable. Bob made the point that it is critical for CISO to speak about and measure risk. The natural follow up questions is then what risks do you measure and how to measure them? Scott Charbo, Vice President at Accenture and former CIO of Department of Homeland Security, presented and discussed that topic. Here are some of key insightful points I would like to share from that discussion.
Risks exist in every part of the business. Security risk is one type of risk. Other risks include privacy risk, compliance risk, credit risk, environmental risk, disaster risk, third-party risk, and much more. CISO organization has traditionally dealt with information security risks, especially around threat and vulnerability and access management. These are topics that traditionally reside exclusively within the security function and the CISO has control over it. While some organizations are more mature than others, implementing proper technologies and processes, and translating these threats into some type of risk metrics is something most CISOs are very capable of addressing. What is increasingly evident is the challenge of security risk emerging from other part of the enterprise that the CISO’s organization does not have control of, and in a lot of cases, not even have the awareness of or visibility to. These risks are now growing exponentially because introduction of new consumer and enterprise technologies. Scott’s presentation was titled “An Expanded Security Ecology With Outcomes In Mind”. Scott introduced some interesting concepts about what risks to measure, how and where to measure them, in order to optimize the deployment of precious security resources.
The dynamics within an organization is all based on “flow”: the flows of information, processes, services, and data on our networks. Today businesses are already managing the availability of these flows. From IT’s perspective, the focus has traditionally be on how many 9’s are required in availability and how do we maintain that availability. From security’s perspective, it has been about managing the security of those flows. Traditionally the CISO organization has deployed various tools like IDS, IPS, Content Filtering, SIEM and now DLP to help secure these flows. Risk reports from these tools and data points do not take into account risk factors from policy, processes and other operations. Still the focus has been on monitoring the data points IT knows about and has controls over, namely IT infrastructure and endpoints.
When a bad thing happens and disrupts the flows, whether it’s breaches, outages, etc, then often some new exposure in the broader flow is identified. These new previously unknown risks that organizations uncover can often be traced back to sources outside of the IT organization. Management of flows across departmental boundaries tend to be by policy, manual processes for compliance, service levels, etc. To gain control over certain risks, CISO must expand the focus to the broader organization and put the right controls in other business processes such as architecture, operations, policy and compliance, acquisition, and budget. Too often CISO just resort to implementing compensating controls within IT to protect from risk originated from outside of IT, which are often costly and imperfect. By measuring and managing the risks of broader flows across departments, CISO can better control some of these emerging risks and even prevent some yet unknown risks.
Here are a few examples to illustrate the point:
- To control risk of privilege user access, it may be necessary to monitor the process flow between human resources and data center operations. Accounts may not be reset or removed when a DBA changes job or leaves the company.
- Risk metric should take into account, not only information security, but also policy compliance, process checks, physical security, business value, etc.
- Risk should be assessed as a system or project flows from RFI to procurement to deployment, not only for production, for its budget risk, 3rd-party risk, IT architecture risk, policy compliance risk, security risk, etc.
Successful CISO who can keep up with the growing risk challenges must think outside of the box that is IT and start thinking in terms of the broader security ecology within the enterprise.
How Effective Are Your Policies?
Filed under: Best Practice, Industry | Tags: policy, privacy
Leave a Comment Pravin Kothari
It’s all over the news now that the Supreme Court has agreed to hear a case on employee privacy, specifically regarding the ownership of electronic communications (email, text) generated using company issued computers and cell phones. Needless to say that whatever ruling comes out of this case will have profound impact on privacy rights within the US. What also intrigues me about this case is the effectiveness of policies in an organization. According to the news, Ontario Police Department claims that the department’s privacy policy is very clear on this matter. Now, what do you think is the chance that this policy officer has read that privacy policy, let along have understood its impact on him? How many officers in that policy department do you think have actually read the privacy policy? The answer is probably a very very small percentage. Now think about your organization, do you think your company is doing any better? Do you know what your company’s privacy policy is and how it impacts you? Chances are you don’t. Unfortunately most companies treat policy as a paper exercise. Companies put a lot of effort into writing, reviewing and approving policies, then the effort to socialize and enforce those policies take a steep dive. Most companies just send out an email or a casual reminder to all employees once a year. A few more companies request employees to attest to the fact they read it and also make on-line training available. Few actually attempt to measure comprehension and compliance to those policies. Policies are basically controls. You can define all the controls you want, but if you don’t enforce them and measure their effectiveness, then it is just a paper exercise to give you a false sense of warm and fuzzy. As we welcome 2010 and a new age of privacy enforcement in the US, do you know where your policy program stands?
Who Is Responsible For Patient’s Privacy?
Filed under: Industry | Tags: Industry, Personal Identifiable Information, policy, privacy
Leave a Comment Pravin Kothari
Here is an interesting article from The Christian Science Monitor examining 5 very important paragraphs in the new Senate healthcare bill. The proposed bill allows the government to access all electronic medical records in the name of research without patient’s consent. One of the article’s conclusions is that “Congress needs to pass a strong, ethical patient consent law that ensures patients have control over the flow of their personal health information.” Without such mandatory protection from the government, the responsibility of privacy protection will then reside with the care delivery organizations. Whether required by law or not, “trust is a must for ensuring quality healthcare” as stated in the article. Care delivery organizations must stand on the side of their patients and put in the necessary privacy protection measures. On the flip side, if the care delivery organizations are not required to protect patient’s privacy, is that responsibility now passed onto the Government as the data aggregator, or is it passed on to any research institution who access that database? Somebody needs to take the responsibility before all our beloved public official’s medical records get posted on the Internet for everyone to see 
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 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.
Out-of-The-Box vs. Pre-Assembled
Filed under: Industry, Technology | Tags: Architecture, Framework
Leave a Comment Pravin Kothari
In my last blog entry I made the claim that “a product cannot be both OOTB and RDP”. Some of my readers objected to that claim and used SharePoint as an example of a product that is both OOTB and RDP. This deserves some more explanation.
Yes, it is absolutely correct that a software product can be both OOTB and RDP. SharePoint is a great example. Others examples are Lotus Notes, ERP, identity provisioning, and help desk products. With these products, you have lots of rich features you can use OOTB with great configurability. These products also offer you a RDP framework and tools to extend and build your own implementations.
Note that “configurability” is different from “customizability”. All enterprise-class products, including OOTB products, are required to provide configurability and personalization (all via the user interface) to adapt to customer needs and environment. While the ‘customization’ term indicates deeper changes, expensive services, or even programming to build your own implementation that is typically more difficult to maintain and upgrade.
There are many shades of gray here about how OOTB really is OOTB? On one end of the spectrum there are products that many customers use with just configuration to meet their business needs, never have the need to use the RDP capabilities. SharePoint is such an example. On the other end of the spectrum, you have ERP applications that almost no one uses OOTB – almost all ERP applications in production have heavy customization that takes months and years of services to deploy and then again to upgrade. So what should we call products that have a lot of OOTB capabilities but almost all customers still have to “enhance” them using RDP functions? I would rather use the term “Pre-Assembled” products to make the distinction clear from OOTB products. A Pre-Assembled product is simply a starting point for you to build on or finish off (depending on if you are a glass-half-full or glass-half-empty kind of person ).
An analogy here is like buying a storage shed for your backyard. You can go to your local hardware store to buy a shed in a box. There are inexpensive ones that are pretty basic and there are nice ones with more features and options. People buy the ones that fit their needs and budget. More often than not the shed you buy doesn’t have every feature you would like to have or every feature designed just the way you like it, but it meets 90% of your needs and wants without a lot of hassle and effort on your part. This is buying something that is quite literally OOTB. I have 3 of these OOTB sheds in my backyard. The other way is to go to a local custom shed shop and buy something that is tailored to your needs and wants more precisely. The shed shop has many pre-fabricated parts and assemblies you can choose from to make your final shed. They even have sample designs that you can use as a starting point or get ideas from. Most customers use one of these suggested designs as a starting point for their grand design. The shed that ends up in the backyard is customized for you. This is buying a RDP product that is Pre-Assembled. Now, can you go to a custom shed shop and buy a Pre-Assembled model as-is without any customization? Absolutely! Do most people who buy a shed from a shed shop do that? No.
Fortunately in today’s IT GRC world, there are not that many shades of gray in terms of “OOTBness”. You basically have the true OOTB products and RDP framework based Pre-Assembled products. As I said in the last blog entry, there is no single right technology, as long as you understand the pros and cons of each approach and make an informed decision based on your needs and resources. You should always look for “configurability” for flexibility, but you don’t want to involuntarily end up owning a “customized” one-off implementation.
Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization
Filed under: Industry, Technology | Tags: Personal Identifiable Information, privacy
Leave a Comment Pravin Kothari
I ran across this fascinating paper today on privacy by Paul Ohm of University of Colorado Law School. It does a wonderful job of describing landmark researches on the techniques of “reidentification” and their implications on privacy laws, with real-life case studies on AOL, State of Massachusetts and Netflix. The fundamental assumption of the effectiveness of de-identifying data and removing Personal Identifiable Information is now questionable at best. As data mining technology and social networking database continue to develop, as well as computing power become cheap and endless with the development of cloud, it is not difficult to see that current de-identification techniques can become virtually useless. PII will eventually cover every piece of data that can remotely contribute to a “digital fingerprint”.
With such information and technology at our finger tips for good and evil, it is increasing difficult to imagine our privacy to be ever completely safe. From an organization standpoint, it is also evident that privacy protection will become an increasingly difficult challenge. Privacy event/breach is virtually inevitable, so “effort” becomes the key differentiation between whether that privacy event becomes a disaster or a slight incident. Organizations that cannot demonstrate investment in and due diligence for a privacy protection program is simply gambling with their brand reputation.
