Archive for the ‘Automation’ Tag
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.
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.
Risk Mitigation and Remediation Automation – Let’s Not Reinvent The Wheel
Filed under: Best Practice, Technology | Tags: Assessment, Automation, mitigation, remediation
Leave a Comment 
Pravin Kothari
We’re finally at the end of this discussion on defining GRC automation. We discussed mitigation as part of the process automation earlier.
Risk mitigation and remediation are not only an integral part, but also usually the most expensive part of a GRC program as it requires changes in your environment. Some of these changes may require new processes and even additional people if the process is not automated. Automation of GRC processes is still relatively new to most companies. Most companies are still working on front-end process automation. More mature organizations have started working on back-end automation for mitigation and remediation of issues. The cost savings from automating the back-end processes can be very significant.
When the risk, gaps and issues have been identified and prioritized, a response is needed to mitigate the risk , this can include requesting an exception, accepting the risk, transferring the risk, providing compensating controls, launching a campaign, etc. Some of these mitigation actions, e.g. requesting an exception, can trigger their own automated processes. Remediation is one of the possible mitigation actions.
Remediation actions can be manual, partially automated or fully automated. Partially automated remediation actions have some parts accomplished with integration and other parts manually executed. For example, automating ticket integration with Remedy, where appropriate user makes the changes by hand. The technology here is integration to the help desk of your choice. Not a trivial task, but not rocket science either.
Certain remediation can be fully automated and it typically involves integration with some sort of management software. System management software, or the new fancier term “business service automation (BSA)” can apply patches, make configuration or policy changes directly to applications, servers, network and telephony hardware. These applications are the bread and butter of datacenter operations team. Security software such as identity management, secured configuration management, data leakage prevention are able to implement access changes via remote requests as well. Identity management can even reach into ERP applications and implement segregation of duties controls on business transactions. These are the tools of trade for security operations team. There are a number of new and old technologies that fall into these two categories of system management and security tools, and there is no sense for me to inventory these on this blog. What is important to note is that these technologies do not fall under the “GRC” management space. Remember that GRC (capitalized) is a well defined application category, where as “governance, risk and compliance” is used loosely to describe a whole slew of technology solutions that have something to do with compliance and risk…. [The abuse of the term GRC by vendors is a whole topic of its own. I’ll reserve that for venting some other day J] System management and security management software are necessary in their own right, solving operational and compliance problems. The key is for GRC applications to leverage these existing assets and not try to re-invent the wheel by duplicating capabilities already available in the infrastructure.
Whew! That was a long discussion, longer than I expected, actually. I hope you found this thread on GRC automation definition useful.
Control Automation, The Devil Is In The Details
Filed under: Technology | Tags: Assessment, Automation, Common Control, control automation
Leave a Comment Pravin Kothari
Control automation is one of the areas that vendors most often oversell their capabilities. Clever marketing folks use high-level languages to make simple data import into a full blown automation feature. There is no need to spend time talking about mundane stuff like data extraction and transformation. There is not a single product on the market that cannot at least do that. Let’s focus on the key technologies that actually make control automation meaningful. As they say, the devil is in the details. So what technologies do you need beyond simple data import? Once you have the data, you need analysis engine and control testing engine to continuously analyze the information and test the required controls.
Common Control Framework
Automation can help improve efficiency and speed by doing things faster and better than human can, but really good automation should also include process optimization so redundant tasks can be avoided altogether. We like to say at Agiliance: “Don’t just work smarter, remove the work!” Compliance assessment is one area where inefficiency abound in most companies. Silo compliance efforts mean each program (SOX, Privacy, PCI) sends out overlapping set of questionnaires to the application owners. A good compliance automation tool should optimize by leveraging the fact that these standards and regulations have significant overlap in control requirements. Common Control is the capability to cross map a set of controls to the requirements from different regulations and standards. So once a control is tested, the test results can contribute to the assessment for multiple regulations and standards without duplicating work. With Common Control technology, a company can now test once and meet the requirements of many compliance initiatives. In addition to the actual control mappings, the control automation engine needs to have an efficient algorithm to propagate and link control test results back to the program mandates.
Control Testing Automation
After pulling in data from IT management and security systems, the next challenge is to interpret the data to decide if certain controls should be passed or failed based on the data. Assessment applications can often map the imported data to appropriate control, but then require a human to review and make the pass-fail decision. In many cases, the data is straightforward to interpret and human intervention is not really required. A good assessment tool should be able to automate the pass-fail decision using rules technology. The automated assessment can then be presented to a human for optional review.
We’re almost done with the automation topic. We will briefly discuss remediation automation next.
Collaboration and….. why not SharePoint?
Filed under: Technology | Tags: Automation, collaboration, document management, process automation, workflow
Comments (2) Pravin Kothari
Collaboration is the last part of process automation. We briefly touched on it when we discussed assessment. Collaboration is an essential part of GRC because GRC is hardly black and white. GRC is all about different shades of gray. Each organization has to decide for itself which shade of gray is appropriate in each case, whether the topic is compliance level, acceptable risk, or compensating control. The process of coming up with an agreement around policy, procedures, controls, and risk require collaboration among different stakeholders including process owners from the business side.
Collaboration is a mature product category in its own right. Lotus Notes was probably the first major software that started the category as we know it today. In the last few years with the emergence of social networking and the maturity of portal technologies, many of the major software vendors started to use the term Enterprise 2.0 to describe a combination of collaboration, social networking, content management, unified communication and portal technologies. It’s not the best use of our time here to do a deep dive on the various collaboration technologies. You can read Wikipedia or Oracle and IBM’s middleware web sites as well as I can. Instead, let’s dive into 2 questions specific to GRC and collaboration technologies:
- What is unique to collaboration technologies when applied to GRC?
- Why is a generic collaboration tools like SharePoint not sufficient for GRC use? Why does a GRC tool requires integrated collaboration capabilities?
Collaboration and workflow are two separate technologies, even with workflow’s new fancy term “business process automation”. Collaboration technologies are typically used where lots of people are involved and their interactions are more free formed. There is usually no well defined end-to-end process involved, and there is little structure around task and data ownership. In many cases, there are not even clearly defined objectives for the collaboration. Wiki is a good example of that. On the other hand, workflow is used for structure processes. There is usually at least one well defined path for how different tasks and events should happen, who is responsible for each step in the workflow, and each workflow has a start and an end. Workflow naturally fits into many of the business processes, especially transaction centric ones in most ERP applications. In addition to collaboration and workflow, there is a third leg to this stool: document management. Document management is for gathering, managing the lifecycle, and sharing documents for policies, process narratives, procedures and evidences.
GRC use cases require these three technologies to be equally well developed and integrated. They need to work well together, not separately. Most of the processes in GRC are procedural in nature, thus workflow is important; for example: incident management, control assessment, and policy approval. However, many of the tasks or groups of tasks in these processes require a more collaborative interaction; for example: policy authoring, assessment of control, and determination of criticality and business impact. In order to have a good user experience, a good GRC tool needs to integrate collaboration and workflow technologies together well. Since many of these processes also involve documents such as policy and compliance reports, document management is also intertwined. This is fairly unique among enterprise applications. Only a few other applications have this unique combination of requirements. Contract management and Product Lifecycle Management products come to mind. So if you are shopping for a GRC application, look for good integration between workflow, collaboration, and document management capabilities. As to what qualifies as “good” integration, that is a loaded question and require getting into the weeds on feature design. We will selectively discuss various features going forward.
One of the most common questions I get is from SharePoint customers asking why they need GRC solutions when they already have SharePoint deployed. This is especially the case when customer is looking at policy management use cases. SharePoint is a generic content management and collaboration application. This makes it a great tool for getting all your documents and evidences collected and shared. SharePoint has rudimentary workflow capabilities, but more importantly, lacks the context of assessment and stakeholders associated with each process and assessment. It would be difficult to use SharePoint to enforce any formal risk and compliance assessment process. This bring us back to the point that GRC is one of the few unique applications that require a tight integration between document management, collaboration and workflow, so a generic collaboration or workflow platform alone cannot meet the use cases well. Any attempt to address the use cases using generic tools would result in significant custom integration work.
We’ll discuss control automation next time.
Mitigation
Filed under: Technology | Tags: Automation, mitigation, process automation
Leave a Comment Pravin Kothari
Let’s continue our discussion on process automation.
Once an assessment is done, if certain gaps or weaknesses need to be corrected, we go into the mitigation process. Mitigation does not always have to be remediation – for example it could be simply transferring risk or describing compensating control. In terms of process automation, mitigation has three sub-components:
- analysis, prioritization, and decision making
- review and approval
- generate request
Following mitigation, any actionable request must be assigned to an owner to carry out the action. In IT, this is often someone doing manual work based on a helpdesk ticket, but for many systems, the correction action can be fully automated using system management and provisioning products. Companies like HP, BMC and Cisco have many such products, often under the product category of Business Service Automation or Data Center Management. This is often referred to as Remediation Automation. We’ll discuss that later.
First part of mitigation is to figure out what action needs to be taken if any. This involves analyzing the gap or issue identified or a reported incident. This usually involves an analyst doing analysis using reports, dashboards and other form of contextual data. For common and straight forward issues, the decision making process can be automated using rules. For example, if a database doesn’t have the latest security patch, then the simple decision is to apply the latest patch with a priority based on criticality of the database and severity of the patch. For more complicated issues, we still need human doing analysis and making the decision on what needs to be done, when and with what priority. Besides simple reports, dashboards, metrics and logs, the interesting technology here is simulation and risk modeling. Mitigation decisions often are not black and white. For some of the issues, analyst may decide to simply accept them and not do any mitigation if they may not pose enough risk. How much should be done requires balancing cost vs. risk. Using a GRC application, an organization can build risk models to measure and quantify (and even monetize) the risk from the gaps. A good risk model enables the user to build scenarios and do simulations to see how the cost compares with the benefit for different mitigation options. The organization can make an informed decision on how much mitigation makes sense if any. Risk modeling techniques are very interesting and extensive topic in its own right. We’ll certainly be talking about that in depth later.
Once a mitigation plan has been determined, it often needs to be reviewed or approved in the context of the whole assessment. This obviously requires workflow and collaboration capabilities from the GRC application. We’ll discuss collaboration more in detail when we discuss the third component of process automation in the next blog.
The third and last part of mitigation is to generate an actionable request once the mitigation decision is done and approved. Some of the mitigations may generate a ticket or notification of some sort. Most organizations have at least one ticketing system in place. The most common ones are BMC Remedy and HP Open View Service Center (Peregrine). For some of the mitigations the GRC application should be able to automatically create a ticket into the enterprise’s ticketing system and be able to pull in updates when the ticket status is changed. To achieve this, the GRC application needs to have connectors to the ticketing systems, as well as flexible integration architecture to enable easy configuration. The flexibility and ease of configuration is very important because ticket format and list of fields in a ticket varies greatly from company to company. Issues such as required fields and dependent fields can make the integration fragile if not done correctly. In cases where the mitigation is not executed through a ticketing system, then the GRC applications should have basic abilities to manage mitigation actions, send out email alerts, a user interface to let users view the alerts and record the actions taken.
Next time we’ll talk about collaboration and finish up our thread on process automation.
Assessment Process Automation
Filed under: Technology | Tags: Assessment, Automation, process automation
Leave a Comment Pravin Kothari
Let’s continue our discussion on automation.
Assessment process is the most important part of any GRC and audit program. There are many types of assessment as well (I did say the terminology is confusing). Automated control assessment we will discuss later. Assessment or self-assessment is the process of surveying stakeholders with a list of controls and risk questionnaire, followed by reviewing the findings, then deriving some measurements and mitigation actions. Some common examples of assessments are:
- Assessment of controls to measure compliance level
- Assessment of policy awareness and comprehension
- Assessment of risk, impact and vulnerability
- Assessment of asset, applications, and even vendor to derive criticality and risk levels
Many of these assessments have special terms of all of their own, such as Risk Assessment, Vendor Risk Assessment, Application Risk Self-assessment, Policy Attestation, and Asset Categorization. We will discuss many of these specific areas in more detail in future blogs.
Some people think assessment automation is the same as workflow or survey. In actuality, survey and workflow are just two of the enabling technologies needed for assessment automation. A full featured assessment application should have the following key capabilities:
- Survey authoring, , versioning and distribution
- Collect structured, tabular, data-series, and free-form responsesGather separate independent opinions from multiple stakeholdersResponder can upload documents as evidences
- Highly configurable workflow that is capable of interacting with different stakeholders for each step of the workflow
- Smart survey engine capable of automatically matching individual questions to the appropriate stakeholders based on roles and user profiles
- Flexible survey delegation down to the question level
- Statistics based calculation and risk scoring
- Integrated assessment of different entity types, e.g. process, location, asset, application, vendor
- Automated reminders and multi-tier, rule based escalation
- Scheduling, automated recurrence e.g. quarterly, and administration of assessments
- Integration with automated controls for data collection, validation, and to find discrepancies
- Integration with remediation to make assessment findings actionable
A good assessment process automation application should offer rich and flexible capabilities listed above without the need for scripting or programming, as well as it should offer elegant integration between all these capabilities. Trying to do custom development with separate modules is a sure exercise in frustration.
We’ll continue our discussion next time on mitigation. Have a great weekend!
What is GRC automation?
Filed under: Technology | Tags: Assessment, Automation, collaboration, control automation, process automation
Leave a Comment Pravin Kothari
Each field has its own confusing terminology. Unfortunately GRC probably is amongst the worst. Even the term “GRC” itself is confusing, with every technology vendor claiming their solution helps customers meet GRC requirements. This causes confusion about what exactly is core GRC solution. We will reserve that fun discussion for another day.
Automation is one of the confusing terms in GRC. Every vendor claims they do GRC automation, but offering different degree of automation, and it is really up to the customer to figure out what the differences are and how the features fit their needs. Let’s attempt to dissect and define “GRC Automation”.
End-to-end GRC automation has 3 main components:
- process automation
- control automation
- remediation automation
No single GRC vendor is strong in all areas, but most vendors claims they have all of these covered at a high level. Customers need to educate themselves about the details and ask vendors the tough questions to get through the marketing hype.
We’ll go down the list. Let’s start with process automation.
Process automation refers to the automation of orchestrated task flows. In GRC speak, this is further restricted to manual tasks. So we are basically talking about workflow of collecting and routing policy, control, risk, etc. information that was done using Excel and Word documents. For you workflow experts out there, this is more precisely just “human workflow”. For you BPEL experts out there, this is the equivalent of “BPEL for People”.
Process automation is characterized by having most of the workflow steps involving human interaction. There may be some rule driven automated tasks interwoven to help with data transformation, escalation and routing tasks. Typical application of process automation within GRC solutions are:
- assessment
- mitigation
- collaborative authoring of policy, procedures, controls, and risk information
We will continue to discuss these areas of process automation as well as the rest of the automation categories. Sorry for having to break this out into multiple blog entries. It’s a long discussion and I have a day job of building products 
