Archive for the ‘Best Practice’ Category
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.
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.
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.
What’s next for vulnerability management? How to complete the picture?
Filed under: Best Practice, Technology | Tags: risk, Risk based security, Security, Threat And Vulnerability
Leave a Comment Pravin Kothari
Vulnerability assessment tools (VA tools or scanners) have been evolving from network-based to host-based to application scanners (web-apps and databases) and even to source code scanners. Tackling known exploitable vulnerabilities is an obvious activity towards managing risk and compliance. Enterprises have spent millions in vulnerability management as part of risk and compliance management programs. Yet, management is struggling to get visibility and answers for basic questions such as – are we focusing on risks that matter to our business? Are we in compliance? Are we secure enough? Is our sensitive data not vulnerable to breaches? They have started to realize that vulnerability assessment tools are just a piece of the broader risk and compliance management puzzle.
Some of the challenges facing vulnerability management programs are the following:
First of all, scanners do not have complete information. There are multiple scanners in deployment – each providing report of its own world. On the other hand, there are number of vulnerabilities that scanners cannot get to due to installed security on servers and desktops. Also, scanners usually focus on open ports and network accessible vulnerabilities, and not as much on installed software vulnerabilities. Moreover, scanners do not address “zero day” / “early warning” vulnerabilities. Subscribers of “Early Warning” advisory services, such as VeriSign iDefense, end up with manually reviewing advisory alerts and are unable to track affected systems and software in their environment.
Second, scanners do not connect the dots. For instance, they do not usually have access to business context of target systems and applications, such as Confidentiality-Integrity-Availability-etc. requirements. 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. Prioritization needs to take business details of the affected asset into consideration. Scanners generate a lot of data, often too much noise for the user to properly review and address in a timely manner – which exacerbate the issue especially with multiple scanners. Not having an efficient way of prioritizing vulnerabilities can cause the real serious vulnerabilities to be buried behind more trivial ones, causing significant delays in remediation.
Once a vulnerability is identified, its tracking and remediation process is often manual and error prone as it relies on a patchwork of disconnected technologies. The process typically starts with a human review of the found vulnerability and ends up with user prescribing a remediation action, which usually takes the form of a helpdesk ticket. Tracking of the ticket is again a separate process and it does not loop back to the vulnerability management. If remediation is done by a patch management system, it also does not loop back with vulnerability management.
Lastly, vulnerability scanners do not correlate vulnerabilities with the compliance requirements, compensating controls and GRC programs, which are ironically partially funding the vulnerability management. Compliance and risk professionals end up manually copying-and-pasting vulnerability information in their control testing documentation.
Vulnerabilities, configurations, remediation and compliance are managed in functional silos and reported up in silos. Information is all available but they are in disparate systems. Enterprises are starting to realize that manual processes and incomplete silos prevent a unified view and clean picture, and result in duplicate efforts and high cost. They see a need to connect the dots, correlate vulnerability information with configuration, remediation, risk and compliance information.
Next time we will discuss how new technology-focused automated GRC platform can address these challenges.
Gartner Blog: Is your software provider choking at the maintenance trough?
Filed under: Best Practice, Industry | Tags: Gartner, Industry
Leave a Comment Pravin Kothari
Here is an interesting blog post by Michael Maoz of Gartner. I like his proposed strategy of keeping non-differentiating products from the big software companies at the core, then surround that core with products from smaller innovators to gain a competitive advantage for your business. You can clearly see how this scenario is playing out in the security solution space, and is now happening in the GRC solution space.
Operationalize Risk Management
Filed under: Best Practice, Industry | Tags: Automation, compliance, control automation, enterprise risk, ERM, Framework, IT risk
Leave a Comment Pravin Kothari
The last topic of discussion at the Accenture CISO Roundtable was “Operationalize Risk Management”. If you recall, we started the session with Bob West of Echelon One discussing the need for CISO to speak about and measure risk. Then Scott Charbo of Accenture discussed what risks to measure and how to measure them. Mark Lockareff of Agiliance then discussed how do you operationalize these measurements and how technologies can help. Here are some of the key discussion points.
When the analyst community coined the term “GRC” a few years back, they positioned the 3 terms in order of theoretical maturity level. In theory, an organization should figure out how it wants to run its business and operations (Governance), then figure out how to manage risks they face that may prevent it from running its business, then figure out how to assess and report for compliance requirements. This is a maturity model that is perfectly logical, but very difficult to achieve given real world constraints. Given most organizations are on-going operations and must “keep the lights on”, compliance became priority number one. Compliance is relatively the most well understood requirement and the consequence for non-compliance is clear cut. By now most organizations have significant investments in various aspects of compliance, in terms of people, processes, and technologies. Most big organizations are becoming “compliant” and have matured to a point of wanting to fill out the rest of the GRC functions, namely Risk and Governance . Risk is the natural next step since it is better understood and more measurable than governance. So, the real-world maturity model is really “CRG”. Not the way things should be, but it is the way things are.
The next logical questions is how does an organization that has invested heavily in compliance, make the transition to proactive risk management? Can an organization leverage its compliance investments for its risk management initiative? Where are the gaps and what are the next steps?
Organizations that have invested in compliance programs have usually defined set of controls and testing procedures. Most organizations have also invested in some control technologies, such as vulnerability scanners, data leakage prevention, identity management, segregation of duties, log monitoring, etc. The good news is that these control points are some of the same ones required to gauge risk for security, operations, disaster recovery and so on. The fact that controls have already been defined and being tested and enforced is a great start. The issue is that the testing and reporting on these controls are generally done with manual audit processes, involving lots and lots of spreadsheets and processes that are error -prone. As risk is inherently real-time, risks do not cease to exist in-between the audit cycles. So in order to leverage control investments for risk management, an organization needs to be able to make control assessment and reporting near real-time and continuous. To move from a compliance centric GRC program to a risk centric GRC program, an organization needs to invest in automation for control assessment and reporting as well as new processes for risk management.
New automated and integrated GRC solutions leverage existing control technology investments and elegantly combine automated data from the environment and deployed controls with the information from operational controls, audit processes and mapped risk models. By such integration, GRC solution can enables continuous risk and compliance management.
The key to success for most IT projects is to roll out incrementally and achieve realistic goals with clearly demonstrable business benefits at each phase. GRC automation projects are no exceptions. There is no need to boil the ocean or throw the baby out with the bath water. Build on existing investments and processes – is the key to move up the “CRG” maturity cycle.
This will probably be my last post for the year. So happy holidays and a very happy new year to my fellow GRC professionals.
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?
