Archive for the ‘Technology’ 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
GRC and the Cloud
Pravin Kothari
This is RSA Conference week, so let’s take a short break from our threat management discussion and talk about RSA Conference a little bit.
It’s always interesting attending the RSA Conference. You meet new people and catch up with old friends. Besides seeing new technologies, one of the most fun thing to do is hear how different vendors do the marketing spin and try to align to the theme of the conference, and trust me, some spins are really stretching it. This year’s theme is Cloud Security. A few announcements came out from GRC vendors (and their parent companies 
), almost all high level with no details, but just to get the company name and the word cloud in the same press release.
So what exactly does cloud mean to GRC, and vice versa?
- GRC solution in the cloud: This is being able to buy GRC solutions using the SaaS model and being able to consume it as another solution from the cloud. Nothing too new and exciting here. No different than people using salesforce.com for CRM. Any GRC vendor worth its salt has a SaaS offering.
- Integrate GRC to the cloud: As companies are starting to buy IT solutions that are cloud based, GRC solutions must be able to connect to cloud based applications to provide data collection and automation. Unlike on-premise systems where you can always resort to the flat file dump and import method of integrations, not all cloud based solution vendors can support such manual processes. GRC solutions must be able to offer out-of-the-box integrations to these cloud based solutions, for example, Agiliance product can connect to cloud based Verisign iDefense and QualysGuard to collect the data and evidences to drive automated compliance and risk management,
- Assess the risk of the cloud services: When a system is on premise, it is easier to assess its risks. You know where the server is located, you know how data flows, you can control who has access to the machine and the data, you do the back up and disaster recovery. All these things we know about on-premise solutions become “cloudy” when the solution goes to the cloud, pun intended . For an organization to embrace cloud based solutions, an organization must be able to assess the risk of these cloud based solutions and IT service providers, or it will risk violating international regulations and industry mandates on data privacy, exposing intellectual properties and other business data to competition, unable to ensure system availability and business continuity, just to name a few. An organization must have robust vendor risk management process and solutions in place before it can adopt cloud based solutions for critical business and IT systems. For example, salesforce.com, an Agiliance customer, performs security risk assessment on all of its 1,200+ partner applications available on its AppsExchange. Salesforces.com needs to ensure its platform and the customer data are not put at risk due to a poorly designed partner application.
- Certification of the cloud: While it is a challenge for a company to assess the risk of all its cloud solution vendors, it is an equal challenge for a cloud solution vendor to meet the assessment requirements from all of its customers. This many-to-many assessment model is highly redundant and not scalable for both the customers and the vendors. What is needed is a certification standard for the cloud. This can be based on either industry standards such as Cloud Security Alliance and BITS Shared Assessments or proprietary ones from a trusted authority. A solution vendor can earn a seal of endorsement by putting its solution through such a certification program periodically. Buying organizations can trust the integrity of the solution knowing the solution has been rigorously assessed by trusted third party. A number of Agiliance customers like Cisco Systems and Bell Canada are already using Agiliance based solutions to automate their security and privacy assessment services. The use of an automated GRC system ensures the consistency and integrity of the assessment process, as well as the quality and consistency of the outputted reports and recommendations. It doesn’t take a strong imagination to think that this can easily translate into a formal certification program, much like what the Big 4 audit firms do for financial reporting integrity.
I would like to hear what insights or comments you may have on how GRC and cloud impact each other.
Completing the picture for a risk-based approach to vulnerability management
Filed under: Best Practice, Technology | Tags: risk, Risk Management, Threat And Vulnerability
Leave a Comment Pravin Kothari
What’s the essential first step for a successful vulnerability management program?
In the last posting, we started talking about the challenges facing vulnerability management (VM) programs. Today, we’ll look at the all-important starting point: gathering all relevant vulnerability information from several sources: scanners, threat feeds, advisories, asset context, etc. The right information can help drive countermeasure decisions in an efficient and risk-based manner.
Vulnerability assessment tools (known generally as scanners) provide a lot of data (with a lot of noise), but at the same time they are missing a ton of information required for VM programs. Scanners cannot get to significant number of vulnerabilities, due to installed security on the network, servers and desktops.
Scanners are not enough.
Running only network-based and web-application vulnerability assessment tools is not enough to find all vulnerabilities as scanners do not touch software applications installed on the host. You will also need to scan the host for vulnerabilities, such as configuration checks for installed software applications and the OS.
Vulnerability assessment is a necessary part of a VM program whether it’s network, application and host-based scanner, but even that is not sufficient. You cannot rely only on vulnerability assessment. You need to bring in information from several other sources.
One excellent source is the NIST National Vulnerability Database (NVD) database of vulnerabilities—it is industry standard, continuously updated, and freely available. It’s a master repository of all published vulnerabilities by vendors, by users and research organizations. That information can be filtered to be relevant to technologies deployed in your environment. For example, if you know you have Firefox v3.5 on selected systems in your environment, you can use NVD’s latest Firefox v3.5 vulnerabilities to identify all affected systems without running a scan. Such complementary techniques are valuable when scanners are unable to fully scan some hosts and installed software. NVD also provides additional vulnerability attributes to help risk scoring.
Another key piece of information is an external threat intelligence feed, which includes new vulnerabilities discovered by security researchers, underground forums, law enforcement, and others. It also has information about what’s going on in the wild and whether an exploit is available for a given vulnerability – all that information can drive risk-scoring and prioritization. There are also commercial feeds available from VeriSign, Symantec, and so on, that provide advance notice and early warnings on emerging threats – resulting in solid 30 to 60days to deploy compensating controls before that vulnerability becomes public knowledge for exploitation or tested by a scanner.
Similarly, a prudent VM program should also include advisory reports that are provided by your vendors, such as Microsoft and Red Hat, that are relevant to your environment.
Are we missing any other important piece of information?
Yes, one of the most important pieces of information is the business context of target systems and applications. Business context includes how critical the target system is to the business, and its confidentiality, integrity and availability requirements. All the collected security information—vulnerability, threats, advisories, configuration issues, etc.—must be correlated with target systems’ business context for risk scoring and prioritization. Target systems should be linked to higher-level business processes, such as financial reporting, which may be subject to compliance requirements such as SOX.
Such business requirements and threat feeds play a key role in deriving the risk and priority of each vulnerability. A vulnerability affecting a server that stores credit card information should not be treated with the same priority as the same vulnerability affecting a server that stores publicly-available documents. Not having an efficient way of prioritizing vulnerabilities and threats can cause serious vulnerabilities to be buried behind more trivial ones, causing significant delays in remediation.
Seeing the whole picture
Basically, your vulnerability management program should aggregate information from aforementioned sources in order to adapt to the ever changing landscape of threats and to help you provide countermeasures in an efficient and risk-based manner.
Next time, we’ll continue to discuss Vulnerability Management as a key feature of new technology-focused automated GRC platforms. Also, we’ll talk about the next step: Making vulnerability lifecycle management smarter and more efficient with GRC platforms.
Kuppinger Cole: Linking GRC to security
Filed under: Technology | Tags: GRC, Kuppinger Cole, Security
Leave a Comment Pravin Kothari
Here is a nice blog entry by Martin Kuppinger of Kuppinger Cole on the different layers of GRC and how GRC is intimately linked to security.
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.
Is it Out-of-The-Box or Customized Application? Think Upgrade!
Filed under: Best Practice, Technology | Tags: Architecture, Framework
Comments (3) 
Pravin Kothari
Another way to determine if an application is OOTB or Pre-Assembled is to look into the upgrade history of the application. The biggest issue with Pre-Assembled applications is that they quickly turn into custom applications. As business requirements evolve, the customization usually gets more extensive. Why is this not necessarily a good thing? Customization is almost never supported by the vendors. At best, vendors will provide “best-effort” support for area of the application that has been customized. Ultimately, there is the inevitable upgrade challenge. Attempt to upgrade a customized application more often than not turns into a complete redeployment. Redeployment is obviously time consuming and expensive. As I have said many times now, as long as that is a trade-off that is understood upfront and is a desired trade-off, then there is nothing wrong with selecting a RDP based application. Too often, we see companies unknowingly go down the customization path and be surprised with the effort and cost associated with such a strategy.
A customized application is expensive to the customer, and can be equally expensive to the vendor. Patching, new feature design, platform certification all become exponentially more difficult as the engineering team now has to account for more variations and unknowns in the install base. The fact that customers cannot upgrade easily, usually results in the vendor supporting many different versions of the product. Even very old versions still need to be maintained because it is required by important customers. There are numerous stories in the software industry about vendors struggling to support legacy products because all the engineers that worked on the legacy code had left the company. New engineers support the product by reverse engineering the legacy code. The solution to this problem is usually to ask the customer to buy more consulting services or premium support.
Upgrading a customized application can involve dealing with any of the following, ranked in increasing order of difficulty:
- Manual apply the upgrade and migrate your data because vendor’s upgrade tool is not compatible with the customization.
- Re-apply all customizations after automated or manual upgrade
- Update customization due to changes in data schema
- Update customization due to changes to API
- Update customization due to changes in product behavior
- Update customization for past workarounds when new features are introduced
- Update customization that uses undocumented API
- Difference between new vendor code and custom code to figure out what has changed and merge customization into new vendor code
If you are looking for a OOTB product, then you should ask deeper questions about upgradability during the product selection process. The answers will help you calculate the total cost of ownership over the long run. Ask the vendors and check with customers who have been using the product for at least 2 years and have done at least one major version upgrade. Some questions to ask:
- How many different versions of the product are in use? A true OOTB application should have no more than 2 major releases, each with a couple of minor releases still in production.
- How long does a typical upgrade project last? Is it a few days or weeks, or is it more like 3 to 6 months or even longer?
- What percentage of customers use the latest major release? It should be over 50% six months after a major release.
- What percentage of customers has successfully upgraded without using paid services?
One lame response you will often hear from vendors when justifying why their upgrade statistics are less than stellar is that while their software is easy to upgrade, some customers just do not want to upgrade. Every customer I have ever met, especially for emerging market such as GRC, wanted to upgrade to the latest version in a timely manner. Customers who put off upgrading for a long time do it for a simple reason: the pain of upgrading outweighs the pain of living with old software. It’s as simple as that.
A Hammer Factory
Filed under: Technology | Tags: Architecture, Development, Humor
Leave a Comment Pravin Kothari
All this discussion about OOTB and PDP reminded me about this post from Joel on Software. It is simply hilarious. It also does a nice job of boiling down my last 2 blog entries to “Are you looking to buy a hammer or a hammer factory?” A little humor before the weekend.
Out-of-The-Box vs. Pre-Assembled
Filed under: Industry, Technology | Tags: Architecture, Framework
Leave a Comment Pravin Kothari
In my last blog entry I made the claim that “a product cannot be both OOTB and RDP”. Some of my readers objected to that claim and used SharePoint as an example of a product that is both OOTB and RDP. This deserves some more explanation.
Yes, it is absolutely correct that a software product can be both OOTB and RDP. SharePoint is a great example. Others examples are Lotus Notes, ERP, identity provisioning, and help desk products. With these products, you have lots of rich features you can use OOTB with great configurability. These products also offer you a RDP framework and tools to extend and build your own implementations.
Note that “configurability” is different from “customizability”. All enterprise-class products, including OOTB products, are required to provide configurability and personalization (all via the user interface) to adapt to customer needs and environment. While the ‘customization’ term indicates deeper changes, expensive services, or even programming to build your own implementation that is typically more difficult to maintain and upgrade.
There are many shades of gray here about how OOTB really is OOTB? On one end of the spectrum there are products that many customers use with just configuration to meet their business needs, never have the need to use the RDP capabilities. SharePoint is such an example. On the other end of the spectrum, you have ERP applications that almost no one uses OOTB – almost all ERP applications in production have heavy customization that takes months and years of services to deploy and then again to upgrade. So what should we call products that have a lot of OOTB capabilities but almost all customers still have to “enhance” them using RDP functions? I would rather use the term “Pre-Assembled” products to make the distinction clear from OOTB products. A Pre-Assembled product is simply a starting point for you to build on or finish off (depending on if you are a glass-half-full or glass-half-empty kind of person ).
An analogy here is like buying a storage shed for your backyard. You can go to your local hardware store to buy a shed in a box. There are inexpensive ones that are pretty basic and there are nice ones with more features and options. People buy the ones that fit their needs and budget. More often than not the shed you buy doesn’t have every feature you would like to have or every feature designed just the way you like it, but it meets 90% of your needs and wants without a lot of hassle and effort on your part. This is buying something that is quite literally OOTB. I have 3 of these OOTB sheds in my backyard. The other way is to go to a local custom shed shop and buy something that is tailored to your needs and wants more precisely. The shed shop has many pre-fabricated parts and assemblies you can choose from to make your final shed. They even have sample designs that you can use as a starting point or get ideas from. Most customers use one of these suggested designs as a starting point for their grand design. The shed that ends up in the backyard is customized for you. This is buying a RDP product that is Pre-Assembled. Now, can you go to a custom shed shop and buy a Pre-Assembled model as-is without any customization? Absolutely! Do most people who buy a shed from a shed shop do that? No.
Fortunately in today’s IT GRC world, there are not that many shades of gray in terms of “OOTBness”. You basically have the true OOTB products and RDP framework based Pre-Assembled products. As I said in the last blog entry, there is no single right technology, as long as you understand the pros and cons of each approach and make an informed decision based on your needs and resources. You should always look for “configurability” for flexibility, but you don’t want to involuntarily end up owning a “customized” one-off implementation.
