Archive for the ‘Technology’ Category
Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization
Filed under: Industry, Technology | Tags: Personal Identifiable Information, privacy
Leave a Comment 
Pravin Kothari
I ran across this fascinating paper today on privacy by Paul Ohm of University of Colorado Law School. It does a wonderful job of describing landmark researches on the techniques of “reidentification” and their implications on privacy laws, with real-life case studies on AOL, State of Massachusetts and Netflix. The fundamental assumption of the effectiveness of de-identifying data and removing Personal Identifiable Information is now questionable at best. As data mining technology and social networking database continue to develop, as well as computing power become cheap and endless with the development of cloud, it is not difficult to see that current de-identification techniques can become virtually useless. PII will eventually cover every piece of data that can remotely contribute to a “digital fingerprint”.
With such information and technology at our finger tips for good and evil, it is increasing difficult to imagine our privacy to be ever completely safe. From an organization standpoint, it is also evident that privacy protection will become an increasingly difficult challenge. Privacy event/breach is virtually inevitable, so “effort” becomes the key differentiation between whether that privacy event becomes a disaster or a slight incident. Organizations that cannot demonstrate investment in and due diligence for a privacy protection program is simply gambling with their brand reputation.
What exactly is “Out-of-The-Box”?
Filed under: Industry, Technology | Tags: Architecture, Development, Framework
Leave a Comment Pravin Kothari
In Gartner’s latest MarketScope for IT GRCM in Q2 2009, Gartner did a great job identifying the two very different approaches taken by vendors in this space. Gartner called these two approaches OOTB (Out-of-The-Box) and Rapid Development Platform. Here is exactly how Gartner described them in the document:
“OOTB products are designed to work without significant customization or configuration beyond entering the control, asset and risk content specific to the enterprise. OOTB products are characterized by vendor-provided content for templates, workflow, sample controls and mappings.”
“Rapid development platform products are characterized by flexibility, which means they may be more-closely aligned with customer requirements, but they may also require services to customize and configure…. Organizations should beware of products that can do ‘anything’ except for very little OOTB without consulting assistance.”
The leading vendors in this space are evenly divided in the two camps. In case you are wondering, Agiliance RiskVision is in the OOTB group.
Like so many things in enterprise software, all is well until the marketing folks started to abuse the words (I can already hear my marketing VP coming down the hallway… he reads my blog 
). If you go through the various vendor’s web sites and product literature, practically every vendor is claiming their products are OOTB, because it sound so good to the customers. In fact, many of the RDP (Rapid Development Platform) vendors have gone out of their way during the sales cycle to make their product demo like OOTB, while still touting the infinite flexibility of their product over the “other” OOTB vendors. Oh yes, they’re trying to have their cake and eat it too.
There is not a single right approach. You can’t say OOTB is better than RDP or vice versa. It’s all a matter of fit. Each customer must first determine what type of organization are you? In order to determine which approach is the right fit for your organization, ask yourself these questions:
- How much technical resource do you have to build and maintain the solution?
- What is your budget for both initial deployment and on-going maintenance?
- How much time do you have for delivering the results?
- How often do you expect to upgrade and patch the system?
- How extensive is your deployment? How many integration points do you have?
- How much flexibility do you need from the product?
- Do you have any flexibility to adopt best practices or do you have to replicate your existing manual processes (or legacy processes) exactly?
While there is a no universal “right” approach for all customers, there is a universal truth: A PRODUCT CANNOT BE BOTH OOTB AND RDP”. These are mutually exclusive approaches to product design. In the next few blog entries, I will drill down a little bit into this topic and would love to hear your feedback on this topic.
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.
Control Automation
Pravin Kothari
Process automation is a critical component of GRC automation, but it’s only 1/3 of the whole story. The other 2 are Control Automation and Remediation Automation. Process automation is all about making people work together more efficiently and ensure processes are followed and procedural controls are enforced. Process automation does not address the issue that a lot of these manual tasks such as filling out surveys and calculating risk scores can all be automated from data already available from their environment. These are data already being collected and analyzed by the vulnerability scanners, configuration checkers, log management, identity management, database security, and host of other technologies. Most companies have invested millions of dollars into these control technologies, but when it comes to GRC automation, companies still send control questionnaires in spreadsheets or surveys to the business owners, application owners and security teams to fill out manually.
Control automation tries to leverage this readily available data to automate the control testing and evidence collection process, so people can be relieved of the tedious and repetitive tasks and focus on more important tasks that require human judgment and rationalization. Control automation improves data quality and reliability as manual processes are error prone and subjective. Control automation also makes it practical for a company to increases coverage in terms of both covered assets and expanded sample size. Lastly, control automation also improves data availability as the data is instantly pulled without manual steps, enables sharing/reuse for multiple requirements, and reduces the time and cost of compliance. Control automation is strategic because it is a key enabling technology to achieve closed-loop, continuous, risk-based GRC processes with lower cost, the holy grail of GRC.
Today most company’s GRC processes are compliance driven and periodic in nature. This is the first phase of maturity for a GRC program. A periodic process takes snapshots in time to satisfy compliance requirement, but provides no visibility on compliance issues between audit points. More and more companies are seeing the deficiency of this compliance focused approach impacting their business in negative ways, as they get exposed even after passing say a PCI audit. Risk is persistent and risk does not cease to exist between audit points. A true risk based process requires continuous monitoring of the critical controls, threats and vulnerabilities with automated evidence collection and controls testing. When a control deficiency or vulnerability causes a risk to increase, that risk needs to be assessed and mitigated according to criticality and severity. In a risk centric and continuous process people’s time and energy are spent on managing exceptions, not performing manual data collection and processing tasks. Compliance then becomes simply a branch process that takes a snap-shot-in-time from this continuous flow of data for documentation and audit purpose. The picture below attempts to illustrate what a continuous, risk centric process looks like and where human involvement is concentrated.
From the above picture we can define control automation as the automation of the following task:
- Collect and transform source data
- Map collected data to controls that need to be tested
- Test the controls and attach evidences
- Translate test result and map to compliance and risk requirements
- Compute compliance and risk metrics
- Monitor and raise alerts based on rules and thresholds
- Prioritize issues and alerts to facilitate human analysis
Next we’ll take a look at each of these components in more detail and talk about best practice for adopting control automation.
Earl Perkins of Gartner defines “policy”
Pravin Kothari
It seems Earl Perkins of Gartner also has issue with confusing and over used terms. Here is his recent blog covering the many definitions of “policy” in security and GRC. It is very true that we technology professionals often just assume others speak our language. This is not the case even for people within the small community of security and GRC professionals.
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!
The ongoing struggle between social technologies and privacy
Filed under: Industry, Technology | Tags: data protection, privacy, social networking
Leave a Comment Pravin Kothari
I ran across this article in the New York Times this morning. The City of Bozeman, MT is asking all job applicants to disclose their social network logins and passwords. This is yet another sign of the emerging struggle GRC professionals has with social networking technologies. The pendulum is still swinging between personal privacy and organizational data security. As the pendulum comes to a rest, expect new technologies to emerge to help manage that balance. I will blog more on the social networking technology as related to GRC at a later time.
