The Compliance Storm on the Horizon: Seeing through the Cloud of GRC

September 17, 2012, by | Start Discussion

Industry analysts and vendors throughout Asia and the Pacific Rim anticipate an extension of the compliance movement, further confounding the ambivalence and inconsistencies relating to matters of Governance, Risk and Compliance. As anxiety heightens over when the next "Big Problem" will hit the Internet (and most are betting it will occur via the cloud), there are some things that systems administrator and C-level executives can do to fortify their IT business processes against that anticipated storm that's looming just over the horizon, to reduce risk and potentially stay dry and safe when the weather changes.

Facing the reality that all Internet-connected systems are doorways of risk is not easy for IT administrators. But since more than 90% of all security risks exploit known system vulnerabilities according to Gartner (which has been the case for more than a decade), the controversy of "slow to react" is often the passive consequence from "failing to plan." Add to this the fact that organizations can no longer hide behind the "we didn't know what was happening" defense, and matters concerning "security risk management" become issues of "business contingency planning and accountability," rather than matters surrounding governance, risk and compliance initiatives.

In other words, when the storm comes—and it will—organizations actually can be prepared, and GRC has nothing to do with it.

Umbrellas of Compliance

In recent years, many organizations have felt the heavy hand of standards and compliance knocking on their doors, regardless of industry. For American-based companies, and their respective APAC-based partners and affiliates, much of the compliance push comes from often interpretive and subjective standards policies. Almost a decade old, the Sarbanes Oxley rules, for example,  continue to stand at the center of the compliance controversy for banks and business, including for virtually any organization wanting to transact with U.S.-based companies abroad. With its reach extending into Asian markets as a growing benchmark of expectation, SOX and other frameworks and methodologies, such as ITIL and COSO/CobIT – along with ISO-based standards – are beginning to thunder through Asia’s business communities as well. With the rapidly expanding acceptance of cloud-based technology adoption, “Cloud Management” issues and other cloud-related topics now flood events, trade shows, publications and product lines, thereby creating a new climate for further GRC oversight.
According to Singapore-based Cloud Security Alliance director Aloysius Cheong, “Singapore and Hong Kong have similar approach in developing cloud standards and using standards as a way to encourage efficiency and effectiveness of productivity of companies. Both Singapore and Hong Kong have country-level standardization efforts supported by their relevant national standards body.”

Still, according to many of the current affairs topics relating to ITSec in APAC, much of the concern is based on the ages-old problem of gaps in operational policy. It seems like rain clouds act no differently today than they have in the past—they get things wet. But what of the hype that surrounds all of these issues of compliance? Do these compliance umbrellas really provide a solid shelter under which businesses can feel safe from stormy weather?

From a general perspective, compliance standards are usually reaction-based initiatives, meaning that for the most part, they were created after trends in how information is/was exploited become status-quo.

Take, for example, health care security compliance matters. Back in the 1990s and before, patient records were often available to the highest bidders—and those “bidders” were usually attached to making money in the health care markets, such as pharmaceutical companies (profiting from inside information on who needed certain medicines, etc.), and insurance companies (interested in cutting their risk to pay-offs by identifying more critical or terminal risk patients ahead of pay-outs). Sure, matters of privacy were always relevant to these issues, but the bottom line was: nobody should be able to exploit the individual records or personal information of people needing medical care for gainful purposes.
Now, at least throughout the United States, Canada and countries adopting the measure, “HIPAA” (Health Insurance Portability and Accountability Act), provides a baseline set of rules and laws that protect such medical-related exploits. Not a bad idea, really, as long as administrators understand this compliance mandate is only a basic roadmap, which can quite possibly initiate additional concerns for the organization—sort of like wearing a raincoat out in bad weather, but forgetting to avoid stepping in the puddles.

Whether it be a health care mandate, a financial policy requirement (like PCI/DSS), or even a baseline security operational policy, these often ambiguous standards further the confusion IT administrators and their bosses are forced to face as fears of penalties and possible prison time threaten to strike at will. And unfortunately, the sales cycle is all too well-aware that buzzwords like compliance mean good business on which hundreds of IT security vendors build their product marketing models. Often, without appropriate oversight and at least a small measure of IT security experience, common sense is often left out of the equation when organizations implement GRC strategies. As long as the auditors are happy, the executives are too.

Like anything else “Security” related, however, when introducing anything “mandate” a new set of risks may actually make things (dare I say it?) worse than they were before, and could in fact place the organization a greater risk. In other words, if you don’t have the proper understanding of how GRC impacts your operations, find yourself standing knee-deep in unpleasant water.

Preparing for Foul Weather:

Five things to consider prior to those rainy days . . .

Focusing on continued efforts to defend their expensive mission-critical infrastructures from the frequent storms of attacks and exploits, IT administrators are also frequently forced to decide which vendor's story about security makes the most sense (or cause the least amount of confusion). Determining which tools make the right sense to address security risks, while trying to maintain current operational standards of performance puts even more pressure on administrators. "Which anti-virus will best defend my system?" "Will these policy and assessment applications scale to my enterprise?" "Do these firewall settings make my business safer?" And "What do 'intrusion prevention' tools really prevent?" are common questions for the bewildered sys admin.

So, which tools make the most sense? How much "security technology" do you really need to meet GRC objectives? And where and when does the "prevention" actually begin?

IT administrators have raised time and again the fact that their concerns aren't necessarily about the rules themselves – rather, they are concerned with what further risks they might be facing by overlooking something while rapidly moving to meet compliance deadlines, or while reacting to specific incidents or reports of attacks.

1. Compliance is 90% process and 10% technology.

Part of "process" is gaining a full understanding of what's happening "behind the scenes" before beginning to define any sort of policy, or react to any type of mandate.

While there's a lot written about "intrusion prevention" (IPS) technology, in most cases an incident actually has to occur, or a violation of the defined policy must be recorded before tools claiming to be IPS become active. Realistically, even the "IPS" methodology is more reaction-oriented than preventive.

What’s the best way to reduce risk and address “prevention?” Establish a baseline for how you introduce every technology, device, tool set, application throughout the organization, and start by understanding what the common risks are, respective to each of those elements. Organizations can avoid a lot of trouble by performing a basic search on risk trends and configuration and implementation “best practices” for each object/device/app they plan to implement (remember: “90% process”).

2.  Defining an operational policy without first assessing the environment to which it is assigned is too late.

More than 2,000 vendors are vying for your organization’s IT security business and budget. Most of them begin their security lifecycle models at the policy and move forward with varying degrees of success to defend some portion of that policy (assessment, event logging, perimeter defense, etc.). However, since these security policies are often segregated from the rest of the operational controls (i.e., a separate policy for everything else), most times the general market still looks at IT security tools as a way to react to a fraction of a bigger problem (such as an SQL injection, the threat of denial of service, etc.). It’s like looking out your front window and seeing the rain falling while thinking everything remains sunny and unaffected in your back yard.
Administrators may find it easier to manage and enforce a policy after first learning as much as they can about their environment, its settings, and what is necessary to optimize that environment. In this case, knowledge before taking action is key in determining which decisions will have the best results. Administrators will find that gaining a better understanding of their environments will greatly simplify the need to react to a mandate or some other external control.

3. More than 90% of all exploited vulnerabilities are known problems

In Las Vegas (or Macau), those odds would make millionaires out of the homeless! When navigating through rough waters and high seas seafarers know that survival depends on maintaining a true course while ensuring watertight integrity throughout their infrastructure.

Knowing that there's a nine-to-one ratio of where a problem is going to occur (and often with a three- to five-month lead time), plus the capability of gathering thousands of data points about an infrastructure's most intimate configuration settings moves the concept of "risk prevention" to the level of "security empowerment." It just takes a little time upfront to do your homework (like reviewing SANS Reading Room information, checking with the international standards organizations for the latest trend reports in vulnerabilities), or simply “Googling” key phrases related to securing your organization’s infrastructure.

4. Dressing Appropriately for Bad Weather: Identify Your Configuration Weaknesses!

Following a more pre-emptive approach to addressing potential risks, systems administrators might consider a configuration management database -driven data repository as a starting point to preparing for GRC-based mandates (or merely to ensure a high degree of risk reduction based on the most common exploits).

Or, from a cloud-based perspective (and certainly a powerful starting point to ensure web integrity throughout an organization), organizations might consider web-focused security scanning and mitigation technologies. These tools provide a means of identifying and prioritizing risk-based concerns, allowing IT administrators to target their efforts more effectively prior to a risk becoming an exploit.

5. Finding the Silver Lining

In the U.S. a common saying claims that “In every storm cloud there’s a silver lining.” Once administrators have collected that mission-critical data, they can begin to shape an appropriate policy for what should be considered the "standard" of operational expectation, thereby establishing a highly tailored, custom security infrastructure standard of operation, the rules for which also being used to define a GRC policy that would be difficult to argue with—regardless of mandates.

Blending the strong integrity of a CMDB-based approach to policy management further capitalizes on the administrator's ability to address the need for pre-emptive control rather than post-event recovery. In a sense, you can't fix what you don't know is broken, but you CAN plan for risks when you know what you have and how it's working before those risks are exploited.

Somewhere, Over the Rainbow

The old axiom that "knowing is half the battle" certainly rings true where your organization's risk management plans are concerned. The matter of GRC, and Mandate Management (as I like to refer to it), are concerns that are rising along with the tides. Preparing for the storm, however, doesn’t have to consist of an organization spending buckets of extra money and resources—as long as they have prepared ahead of the problem.
Remember that “Risk Management” and “GRC” are only connected when enough organizations have failed to protect their assets or the secure information/assets of their clients or the general public. To avoid long-term damage from potential overreaction to GRC-related operational directives, “Planning” will make the difference between long-term success in keeping your business and its operation safe from the storm and facing the potential of being washed away in the flood.

Author bio not avialable

Leave a Reply