How to Simplify Your Governance, Risk Management and Compliance Process
Filed under: Best Practice, Industry, Technology | Tags: compliance, GRC, IT risk, IT-GRC, Maturity model
Leave a Comment This week’s eWeek has my article on how to simplify governance, risk management and compliance processes with a new model.
Table of Contents:
- How to Simplify Your Governance, Risk Management and Compliance Process
- Roadblocks of Traditional Maturity Model
- Process-Only Technologies Can’t Scale
- A Better Deployment Maturity Model
- Benefits of Vertical Maturity Model
Please give it a read. I would love to hear your feedback on the article.
PCI 2.0 encourages risk-based process: Three things you need to know
Filed under: Best Practice, Industry, Technology | Tags: compliance, eGRC, IT risk, IT-GRC, PCI, PCI Changes, PCI DSS 2.0, Risk-based compliance
Leave a Comment Your compliance efforts should be risk-based, rather than merely security-focused. Understanding your enterprise’s risk profile and prioritizing compliance and remediation efforts based on risk has been a growing industry trend since Agiliance was founded five years ago, and the evolution of the PCI standard reflects that.
The PCI Security Standards Council recently offered a preview of the PCI DSS 2.0 and PA-DSS 2.0, to be released at the end of October. The new standard includes clarifications, additional guidance, and evolving requirements—but no dramatic new requirements. The most significant change, especially in terms of your compliance budget, is the tilt toward a risk-based process. Responding to stakeholder feedback, section 6.2 will now “allow vulnerabilities to be ranked and prioritized according to risk” as part of an effort to “align with changes in industry best practices.” This is an approach that Agiliance has been encouraging for some time.
Risks That Matter
The new PCI standard will formally recognize an organization’s need to identify the risks that matter most to their business and to focus finite remediation resources on their top priorities. In embracing a risk-based approach, PCI is following industry standards such as ISO 27001.
Enterprise executives have complained that they are spending a ton on compliance and security, but can’t get enough visibility, and are not seeing much benefit from their investment. What they are really saying is that compliance efforts are not focused on the risks that matter to their specific business.
Many merchants have chosen only partial PCI compliance, according to Computerworld blogger Eric Ogren, due to the “prohibitive costs…and people to administer it all.” By allowing companies to assess vulnerabilliities based on risk, an enterprise can now be fully PCI compliant while only paying to remediate the exposures that really matter. Your organization evaluates its risk posture in the context of its risk tolerance, and other unique factors, and pulling this integrated view together can be effectively automated.
Risk and the accountability for risk acceptance are, and should be, owned by the businesses that are creating and managing those risks. Tools can automate effective risk management processes, but the results delivered by these tools will be only as good as the underlying frameworks, processes and data structures. Risk managers should develop enterprise-specific definitions of risk, as well as an organizational structure that eliminates conflicts and overlaps in responsibilities among all risk-related specialists.
PCI Security Standards Council General Manager Bob Russo mentioned that the new rules mean that “you can talk about a vulnerability with a Qualified Security Assessor (QSA) and economize for risk tolerance within your business circumstances to make it more flexible.”
Using an IT risk management tool to assess and categorize your risk profile across the enterprise helps identify those remediation efforts with the biggest impact.
Focus on the Big Picture
When you are prioritizing vulnerabilities, you need to consider the big picture, the whole enterprise. The top priority in a small department of your organization might not be important relative to the overall situation.
Security products often bring a narrow, tactical perspective that can create data silos and distract from the strategic view. Gartner Research, in response to the PCI 2.0 preview, recommends “Continue to avoid working with assessors or vendors that push their own remediation services or software.”
The rumors (started by security vendors) that the PCI 2.0 standard would mandate specific tools such as Data Leak Prevention applications turned out to be unfounded. The new standard seems to require a formal process or methodology, not necessary a product, that locates and documents all sensitive data in an enterprise, which has been a practice that IT-GRC products like Agiliance have promoted for years.
Some of the security products can lead to “audit-fatigue” by producing false-positives in thousands or millions. The output of such products needs to be analyzed with a risk-based lens.
Security tools generally produce low-level information, rather than risk-based analysis that is actionable by business users, auditors, or high-level business governance and policy decision makers. As the diagram below illustrates, the Risk Management function supports prioritized remediation, for example, unlike security tools alone.
In contrast with a tactical, security approach, a risk-based assessment of the entire enterprise can take remediation efforts to the next level. By pulling all the issues into a central repository for analysis, the enterprise gains visibility, eliminates silos, and can cut down on manual or repetitive tasks.
All compliance expenditures should be driven by a risk profile. Each item—vulnerabilities, compensating controls, findings, exceptions, or other elements—should be presented in an IT Risk Management tool in a risk context.
When selecting an IT Risk Management tool, make sure that it automates data collection and offers regular synchronization with your assets and patch management tools. Some products start with a one-time import and grow outdated over time. Others require manual effort to link vulnerabilities to your enterprise IT. A tool that receives automated feeds from your environment and automatically correlates the data for analysis, not only reduces manual effort, but also gives you continuous visibility of risk across your enterprise. The new PCI standards encourage you to prioritize risk management based on this holistic view.
PCI DSS 2.0 and PA-DSS 2.0
PCI has been a rapidly changing standard, but in response to feedback received, the standard will begin a new three-year lifecycle from now on. While this may not be great news for vendors who tout their gadgets for addressing upcoming PCI standards, we see this as good for companies that comply with the standard. However, it puts more responsibility on individual companies to follow a proper process to identify and manage their risks.
Besides emphasizing a risk-based approach and switching to a three-year update cycle, other notable highlights are a new scoping methodology, coverage of virtualization, and a PA-DSS requirement for centralized logging. The new standard does not seem to require any new security tools. Although Visa published a separate best practices for Tokenization, even it did not make the cut for this PCI revision. The new PCI standards will be released October 28 and will be effective January 1, 2011. Agiliance will release revised PCI content within days of the standard’s availability.
Specific Recommendations
- Use risk-based techniques for prioritizing compliance efforts. Expect some savings in compliance costs in 2011 from this change alone.
- Defer unnecessary security products sold as PCI requirements, in favor of an enterprise-wide understanding of your risk exposure and your organization’s prioritized risk. Invest in IT risk management systems and processes to cut compliance cost.
- With the new three-year lifecycle, plan for the next evolution of the PCI standard (v3.0) no sooner than end of 2013. There may be minor updates with clarification and guidance, but new requirements are not anticipated until PCI 3.0, which would be effective Jan 2014. This would provide stability and significant cost savings.
The PCI standard released at the end of October may not exactly match this month’s preview, but changes this late in the standards process usually amount to fine tuning. I’ll discuss other PCI 2.0 changes in more detail in future articles.
Agiliance recognized as top GRC vendor by Gartner two years running
Filed under: Annoucements | Tags: Agiliance, Automation, Gartner, GRC
Leave a Comment 
Pravin Kothari
This is that time of the year when all the IT GRC vendors hold their breath to see how they are ranked in the Gartner IT GRCM MarketScope. I’m happy to say that for the second year in a row, Agiliance RiskVision has received the highest possible rating of “Strong Positive”. Not only have we retained the highest ranking from last year, we scored at the top for all three core IT GRC capabilities. As a result, we have further separated from other vendors in terms of having the most capable IT GRC solutions. Here are the actual scores:
- Controls and Policy Mapping: 5.0 out of 5.0, highest of all vendors
- Automated General Computer Controls Collection: 5.0 out of 5.0, highest of all vendors
- IT Compliance Dashboard: 4.5 out of 5.0, highest of all vendors
This also gives us the highest score of 4.8 out of 5.0 for the Automated Technology Control Assessment use case. This is a very important accolade because the true value of IT GRC solution lies in the automation. The GRC market is quickly maturing to focus on the Risk component. Risk is dynamic and inherently real time, especially when it comes to IT and security risks. As business processes continue to be automated and data become electronic, every single risk in the enterprise will be correlated to IT and security risks. Thus, it is impossible to manage enterprise risk unless you can manage risk in real-time, and managing risk in real-time requires end-to-end automation. Of all the IT GRC technology components, automated technology control and risk assessment are by far the most difficult to build. This type of automation requires highly scalable engines to perform real time data correlation and calculation across large data sets. I would like to give kudos to my Agiliance engineering team for achieving the highest score on the toughest portion of the evaluate criteria.
Two major changes are noteworthy in this year’s MarketScope. The first is the inclusion of some EGRC vendors and the addition of Financial and Operations GRC Support as the fourth Critical Capabilities. This change is somewhat controversial, because it is based on the hypothesis that the traditional EGRC and IT GRC markets as we know them today will converge into one. While there are signs of that buying pattern, we also see a very strong trend that indicates possible convergence of IT GRC with security and configuration management products. The two different trends are driven by the two different buying centers. CFO and internal audit are the buying centers for EGRC solutions. They are now asking for more in-depth and timely data from IT, thus driving the EGRC solutions to include better IT GRC capabilities. However, CFO and internal audit do not look for the very granular and real time data that CIO and CSO need, so for the CFO buying center, some limited extension of EGRC solutions maybe all that is required. There maybe more IT data, but the data is still static and high level. CIO and CSO on the other hand, are the buying centers for security and configuration management and now IT GRC solutions. CIO and CSO look for real-time risk management and situational awareness with continuous connectivity to the IT infrastructure. CIO and CSO need GRC solutions that can support IT operational requirements. A pure survey and workflow based solution maybe useful to check-the-box for compliance needs, but it is of no practical use as an IT operations tool. So how important is EGRC requirements when you are looking for an IT GRC solution? It depends on what is your function and what are you looking to achieve with the solution.
The second change in this year’s MarketScope is that Garter has done away with the Out-of-the-Box vs. Rapid Development Platform differentiation. The new differentiation is Top-Down vs. Bottom-Up. This new differentiation is a good way to capture the difference between the EGRC vendors and the IT GRC vendors. It is a short-hand to summarize the different buying centers needs we discussed above. The CFO and audit approach is top-down with little detail from IT and security. Top-down approach provides a nice enterprise wide picture quickly, but lacks details and is not capable of reflecting the real-time nature of risk. Bottom-up provides the real-time visibility and ability to react, but can be more narrowly focused on just IT risks. Most organizations will need a combination of both Top-Down and Bottom-Up approaches to be effective. Today no one solution can meet the needs of both buying centers and it is likely that no one solution ever will. The best approach for most organizations is still to buy the best of breed solution based on requirements and roadmap. For CIO and CISO we talk to, they are looking for a strong automation GRC platform that can integrate to their existing IT and security management tools to provide real-time visibility and operations support. They also want the tool to have very good Top-Down capabilities to support process centric use cases. This was my goal when I founded Agilinace years ago and it’s gratifying to have Gartner validate that our solution and approach is a great fit for our target market of CIO and CSO.
Risk-Based Approach to Vulnerability Management – Close the Loop
Filed under: Best Practice, Technology | Tags: process automation, risk, Risk based security, Risk Management, Security, Threat And Vulnerability
Comments (1) Pravin Kothari
In the last 2 postings on this topic of risk-based approach to vulnerability management (VM), we discussed the challenges facing VM programs and then the first two steps of this risk approach: build the big picture by gathering and correlating threat and vulnerability information from sources such as scanners, security advisory feeds, asset DB, and patch management systems. We left off after discussing how to add risk and business impact context to the identified relevant vulnerabilities to help make more informed decisions. Today we will close this loop by looking at the final two steps of this risk based approach, namely risk based remediation, and GRC reporting.
We discussed last time that the risk associated with each vulnerability can be automatically calculated by linking to standard sources like the National Vulnerability Database or from proprietary threat intelligence services like iDefense, Secunia and DeepSight. A good vulnerability management platform should also be able to adjust those published risk scores to reflect the business criticality of the effected asset using asset attributes from internal asset DB. Risk can be further refined by looking at additional data sources such as:
- security configuration policies on the host,
- patch availability and patching status,
- availability of encryption, anti-virus, digital rights management, and remote wipe tools as compensating protections
For example, a vulnerability with a high CVSS score, no patch available from the vendor, affecting a server that holds credit card data or is used by a critical business process should be high risk. The same vulnerability affecting an otherwise identical server, but with full-disk encryption, should have a lower risk score. Once the true risk of a vulnerable asset is assessed, then the appropriate mitigation can be prescribed with available security operation resources focusing on the high risk assets. This type of data correlation is not practical with manual process. IT GRC products with strong security integration capabilities is required to achieve operational feasibility.
Mitigation and remediation can be automated as well. This can be creation and tracking of help desk tickets to trigger manual remediation process. In more advanced organizations that are using patch management tools such as Microsoft SCCM, BigFix, and Altiris, IT GRC products can also trigger patching activities directly. Such integration can also be used for verifying the remediation was actually done.
One of the major reasons for implementing VM today is for compliance or risk management. Compliance requirements such as PCI, HIPAA, FFIEC, NERC require organization to have VM program in place. To close the loop, VM assessment findings need to be folded back into the broader compliance management automation. This is yet another area where automation can greatly simplify the process of:
- mapping VM assessment findings to the specific controls for each compliance requirement or risk metric,
- automatically pass or fail controls based on these assessment findings,
- calculate compliance and risk levels dynamically based on control test results,
- monitor compliance and risk metrics via real-time dashboards,
- generate compliance or risk reports based on predefined templates
For folks that want to learn more about this and hear a customer example, Agiliance recently held a webcast on this topic with the Risk and Privacy team of Deloitte. Deloitte recently finished implementing a next generation threat and vulnerability management program for a large utility customer of ours. This solution featured many of the automation technologies we have discussed in this blog thread. In this webcast Deloitte also covered the methodology they used to help deploy this customer in under 90 days. You can view the recorded webcast here: The Business Benefits of a Risk-Based Approach to Security
Article: How can healthcare organizations get started with GRC?
Filed under: Best Practice, Industry | Tags: compliance, GRC, Industry, policy, Risk Management
Leave a Comment Pravin Kothari
This is a nice article just published on Health Management Technology. It is written by my colleague Ed King. It spells out some very concrete ways a healthcare organization can start using GRC solutions to manage risk and achieve continuous compliance. The 3 top level suggestion are:
- Improve the integrity and efficiency of compliance
- Improve visibility and effectiveness of policies
- Improve awareness of and ability to mitigate risks
Give it a read and I would love to hear your feedback on the article.
Forrester’s Robert Whiteley: Note to CISOs – Be the Automator, Not The Automated
Filed under: Industry | Tags: GRC, Industry, Risk Management, Security
Leave a Comment Pravin Kothari
Here is an insightful blog entry from Robert Whitley of Forrester Research. This is very timely with our recent discussion threads around how CISO must take a more risk centric approach to security and you cannot manage risk effectively without automation. The more progressive CISOs are actively looking to increase the degree of automation around security operations, and at the same time increasing their scope of responsibility to become the Chief Risk Officer for the organization.
GRC and the Cloud
Pravin Kothari
This is RSA Conference week, so let’s take a short break from our threat management discussion and talk about RSA Conference a little bit.
It’s always interesting attending the RSA Conference. You meet new people and catch up with old friends. Besides seeing new technologies, one of the most fun thing to do is hear how different vendors do the marketing spin and try to align to the theme of the conference, and trust me, some spins are really stretching it. This year’s theme is Cloud Security. A few announcements came out from GRC vendors (and their parent companies 
), almost all high level with no details, but just to get the company name and the word cloud in the same press release.
So what exactly does cloud mean to GRC, and vice versa?
- GRC solution in the cloud: This is being able to buy GRC solutions using the SaaS model and being able to consume it as another solution from the cloud. Nothing too new and exciting here. No different than people using salesforce.com for CRM. Any GRC vendor worth its salt has a SaaS offering.
- Integrate GRC to the cloud: As companies are starting to buy IT solutions that are cloud based, GRC solutions must be able to connect to cloud based applications to provide data collection and automation. Unlike on-premise systems where you can always resort to the flat file dump and import method of integrations, not all cloud based solution vendors can support such manual processes. GRC solutions must be able to offer out-of-the-box integrations to these cloud based solutions, for example, Agiliance product can connect to cloud based Verisign iDefense and QualysGuard to collect the data and evidences to drive automated compliance and risk management,
- Assess the risk of the cloud services: When a system is on premise, it is easier to assess its risks. You know where the server is located, you know how data flows, you can control who has access to the machine and the data, you do the back up and disaster recovery. All these things we know about on-premise solutions become “cloudy” when the solution goes to the cloud, pun intended . For an organization to embrace cloud based solutions, an organization must be able to assess the risk of these cloud based solutions and IT service providers, or it will risk violating international regulations and industry mandates on data privacy, exposing intellectual properties and other business data to competition, unable to ensure system availability and business continuity, just to name a few. An organization must have robust vendor risk management process and solutions in place before it can adopt cloud based solutions for critical business and IT systems. For example, salesforce.com, an Agiliance customer, performs security risk assessment on all of its 1,200+ partner applications available on its AppsExchange. Salesforces.com needs to ensure its platform and the customer data are not put at risk due to a poorly designed partner application.
- Certification of the cloud: While it is a challenge for a company to assess the risk of all its cloud solution vendors, it is an equal challenge for a cloud solution vendor to meet the assessment requirements from all of its customers. This many-to-many assessment model is highly redundant and not scalable for both the customers and the vendors. What is needed is a certification standard for the cloud. This can be based on either industry standards such as Cloud Security Alliance and BITS Shared Assessments or proprietary ones from a trusted authority. A solution vendor can earn a seal of endorsement by putting its solution through such a certification program periodically. Buying organizations can trust the integrity of the solution knowing the solution has been rigorously assessed by trusted third party. A number of Agiliance customers like Cisco Systems and Bell Canada are already using Agiliance based solutions to automate their security and privacy assessment services. The use of an automated GRC system ensures the consistency and integrity of the assessment process, as well as the quality and consistency of the outputted reports and recommendations. It doesn’t take a strong imagination to think that this can easily translate into a formal certification program, much like what the Big 4 audit firms do for financial reporting integrity.
I would like to hear what insights or comments you may have on how GRC and cloud impact each other.
Completing the picture for a risk-based approach to vulnerability management
Filed under: Best Practice, Technology | Tags: risk, Risk Management, Threat And Vulnerability
Leave a Comment Pravin Kothari
What’s the essential first step for a successful vulnerability management program?
In the last posting, we started talking about the challenges facing vulnerability management (VM) programs. Today, we’ll look at the all-important starting point: gathering all relevant vulnerability information from several sources: scanners, threat feeds, advisories, asset context, etc. The right information can help drive countermeasure decisions in an efficient and risk-based manner.
Vulnerability assessment tools (known generally as scanners) provide a lot of data (with a lot of noise), but at the same time they are missing a ton of information required for VM programs. Scanners cannot get to significant number of vulnerabilities, due to installed security on the network, servers and desktops.
Scanners are not enough.
Running only network-based and web-application vulnerability assessment tools is not enough to find all vulnerabilities as scanners do not touch software applications installed on the host. You will also need to scan the host for vulnerabilities, such as configuration checks for installed software applications and the OS.
Vulnerability assessment is a necessary part of a VM program whether it’s network, application and host-based scanner, but even that is not sufficient. You cannot rely only on vulnerability assessment. You need to bring in information from several other sources.
One excellent source is the NIST National Vulnerability Database (NVD) database of vulnerabilities—it is industry standard, continuously updated, and freely available. It’s a master repository of all published vulnerabilities by vendors, by users and research organizations. That information can be filtered to be relevant to technologies deployed in your environment. For example, if you know you have Firefox v3.5 on selected systems in your environment, you can use NVD’s latest Firefox v3.5 vulnerabilities to identify all affected systems without running a scan. Such complementary techniques are valuable when scanners are unable to fully scan some hosts and installed software. NVD also provides additional vulnerability attributes to help risk scoring.
Another key piece of information is an external threat intelligence feed, which includes new vulnerabilities discovered by security researchers, underground forums, law enforcement, and others. It also has information about what’s going on in the wild and whether an exploit is available for a given vulnerability – all that information can drive risk-scoring and prioritization. There are also commercial feeds available from VeriSign, Symantec, and so on, that provide advance notice and early warnings on emerging threats – resulting in solid 30 to 60days to deploy compensating controls before that vulnerability becomes public knowledge for exploitation or tested by a scanner.
Similarly, a prudent VM program should also include advisory reports that are provided by your vendors, such as Microsoft and Red Hat, that are relevant to your environment.
Are we missing any other important piece of information?
Yes, one of the most important pieces of information is the business context of target systems and applications. Business context includes how critical the target system is to the business, and its confidentiality, integrity and availability requirements. All the collected security information—vulnerability, threats, advisories, configuration issues, etc.—must be correlated with target systems’ business context for risk scoring and prioritization. Target systems should be linked to higher-level business processes, such as financial reporting, which may be subject to compliance requirements such as SOX.
Such business requirements and threat feeds play a key role in deriving the risk and priority of each vulnerability. A vulnerability affecting a server that stores credit card information should not be treated with the same priority as the same vulnerability affecting a server that stores publicly-available documents. Not having an efficient way of prioritizing vulnerabilities and threats can cause serious vulnerabilities to be buried behind more trivial ones, causing significant delays in remediation.
Seeing the whole picture
Basically, your vulnerability management program should aggregate information from aforementioned sources in order to adapt to the ever changing landscape of threats and to help you provide countermeasures in an efficient and risk-based manner.
Next time, we’ll continue to discuss Vulnerability Management as a key feature of new technology-focused automated GRC platforms. Also, we’ll talk about the next step: Making vulnerability lifecycle management smarter and more efficient with GRC platforms.
Martin Kuppinger blog: What business has to learn so that IT can align
Pravin Kothari
Martin is really on a roll now. A nice follow up from Martin about how security and business functions must be better aligned. This is very timely to my current series of blogs on a risk based approach to security management. GRC and security functions must be better aligned if an organization wants to excel.
Michael Rasmussen’s blog: What Is GRC?
Pravin Kothari
In the last 3 months there has been many threads and blog posts on-line trying to define GRC. Some bloggers and analysts go as far as saying GRC doesn’t exist. Michael Rasmussen’s latest blog offers some very nice ways to look at what GRC is.
