Information Security Today Home

New Books

IT Auditing and Sarbanes-Oxley Compliance
Cyber Fraud: Tactics, Techniques and Procedures
Information Assurance Architecture
How to Complete a Risk Assessment in 5 Days or Less
Information Security Management Metrics: A Definitive Guide to Effective Security Monitoring and Measurement

How GRC Principles Measure Security and Accountability

by Philip Lieberman

Governance, Risk Management and Compliance (GRC) software allows publicly-held companies to integrate and manage IT operations that are subject to regulation. Such software typically combines applications that manage the core functions of GRC into a single integrated package. In addition, GRC software enables an organization to pursue a systematic, organized approach to managing GRC-related strategy and implementation. Successful installations enable organizations to manage risk, reduce costs incurred by multiple installations and minimize complexity for managers.

The key drivers behind an organization's responsibility for GRC can be both regulatory as well as a need to maintain transparency with vendors that demand assurances that even privately held organizations have implemented proper internal controls. There are competing interests in the GRC landscape that range from internal and external auditors that are performing their contractual and mandated duties, to the need to reactively or proactively manage IT risk based on both external factors and corporate culture.

GRC Accountability
Clearly security breaches and their inherent causes and remediation point strongly toward failures in GRC, but the question facing many CEOs is, "what is the appropriate level of resources necessary to balance business interests (i.e. profitability and optimal use of resources) versus regulatory compliance management versus funding a security posture that provides better corporate resilience against threats?" This is a fundamental and high-level issue that, if inappropriately managed, can lead to serious damage or possibly failure of the company. GRC is more than just completing a survey and checking off the boxes; it is a measurement of an organization's viability in the face of serious and continuous threats -- both internally and externally.

The GRC strategy fundamentally falls on the shoulders of the astute CEO and his entire team. The goals of the team are to understand what the operational best practices are from an informed perspective, and implement commercially reasonable controls and processes to manage risk and promote transparency. The trouble in implementing GRC is that most C-level executives and their staff are constantly being faced with one "fire drill" after another. The concept of operational optimization and risk management, as well as investments into protective systems and employee training, can be seen easily as wasteful and non-productive. In a sense, GRC is designed to keep bad things from happening, but this requires one to step back from daily issues and look at the organization holistically and implement better ways of managing security and risk.

In a sense, it is a blessing to many organizations that GRC is mandated. The GRC process forces organizations to regularly review critical areas that would otherwise get little to no focus, and certainly a minimal amount of financial resources. Although inconvenient to many stakeholders, the process acts as a form of vaccine against potential fatal infections that come in the form of physical and electronic attacks. The entire GRC process is not a one-time fix, but a way of making organizations that depend on IT (virtually all do) more robust and secure against a range of well-know threats that are mostly unknown to most executives and their staff.

Privileged Passwords and GRC
The mismanagement of privileged passwords (also known as privileged accounts and privileged identities) is the tip of the iceberg of GRC, but an excellent illustrative point of why mandated GRC exists and when it does not, what the repercussions are. Effectively, the privileged password problem is related to the fundamental issue that most organizations provide: too much access, to too much data, to too many systems, for too long, with no accountability and no controls. In the case of privileged accounts, most organizations allow anyone in the IT department to have full access to every system with no restrictions and no auditing. In fact, in most cases, the most privileged accounts are shared among so many large groups of people that when a breach occurs with these accounts (and it does), there is no record pointing to who or what ultimately caused the breach.

On the other hand, there is a fundamental question one must ask from a simple segregation of duties point of view. Is it fundamentally reasonable that a low level employee in IT has unlimited access to the CEO, CIO, CTO, treasurer, HR and other critical systems whenever they wish? Any IT administrator would say that access should be on a "need to know" and on an "as needed basis" with some sort of approval process before there is any access to sensitive data or systems. Unfortunately, most organizations have no privileged password management system in place, or such minimal controls, that any home-grown system for managing these sensitive assets is effectively nothing more than a security farce.

IT auditors have been writing-up findings about improper management of privileged passwords for many years. These findings have warned companies that critical password have never been changed; IT employees that had left the organization for many years still have access to sensitive systems, and effectively, the company has no controls of access when it comes to their systems.

The job of a privileged password management technology is to inventory all systems, accounts, passwords and where they are used. We then take control over these sensitive accounts and provide a framework that allows access to this sensitive information on a need to know basis, based on segregation of duties. Essentially, the technology implements all of the corporate controls that IT auditors demand as part of their GRC process in the handling of this critical corporate asset. Without the proper software, this task does not get done and virtually the entire organization is put at risk. There is no ROI argument for such software. It is so fundamental to the operation of a company that its lack of implementation puts their entire company at risk for the loss of all assets.

GRC Threats beyond Privileged Passwords
The landscape of IT threats is fundamentally broken down into two areas: primitive threats and high-level threats. For primitive threats, the standard set of keeping software up to date with the latest patches and using firewalls, anti-spam/virus, web filters and intrusion detection devices all do a decent job working together to protect the organization. Some of these primitive threats are not specific attacks to the organization rather attacks on everyone that does not have basic protection mechanisms in place.

High-level threats are more costly to an organization and are specifically targeted toward your company. Responding to this threat requires a change in corporate mindset to assume that protection mechanisms will fail at both the technical level and at the human level, and what will be done to detect and respond to these attacks. These are not theoretical scenarios or low probability.

Consider the effect of an employee that innocently goes to an infected Web site or clicks on a link containing a virus causing his machine to become infected with malware or a virus. In some cases the software is so uniquely written that no existing technology will detect its purpose and, as in Conficker, the software will try to connect to all other systems using privileged accounts. Since most IT departments do not protect privileged accounts and set them all to the same value, the software can then gain complete access to most systems in the company in just a few minutes from any workstation.

Well-positioned and security-aware organizations install network sensors on their infrastructures to detect the existence and progress of internal attacks. These same organizations also monitor rates of traffic and destinations of traffic.

A well-designed and GRC-aware organization would implement the compartmentalization of data as well as access. Storing all corporate data in a single place with no inherent encryption is a disaster waiting to happen. It is certainly convenient to IT and software developers, but it does not make any business sense given the consequences of losing control. Similarly, corporate policies that allow laptops with no encryption as well as allowing employees to download the entire corporate database onto their laptops are also disasters waiting to happen.

Technical convenience is nice, but is it worth the embarrassment and loss that it can bring because no thought was given to GRC?

GRC Principles as Integral Sources of Security
GRC asks the organization to examine IT and operational processes, which gives management a roadmap of what's wrong and how to improve their company. It is up to management to either take the risk or put into place appropriate processes and systems (including consulting, software and hardware to implement these systems) to manage the risks based on reasonable business decisions. Effectively the IT auditor will explain where the company has stored value and where the locks to protect those assets are deficient.

It is said that knowledge is power, and the GRC process provides the knowledge necessary to build a more secure and risk aware/risk respondent company. Some CEOs, CIOs and CSOs will see GRC as a drain on the bottom line with a complete disregard to corporate risk and its consequences. For those organizations, GRC provides no benefits, only costs. To those that see the long term survival of the organization as part of their business plan, GRC is a welcome framework to operate in a dangerous world where IT runs just about every facet of their business.

Best Practices
First, recognize GRC as an asset and the IT audit organization as a friend of the company as a whole. Assume that GRC is a continuous process where the risks are constantly evolving, so the audit process is a constant process, not something that is done once a year as part of a PCI audit. There is no pass or fail in GRC or an IT audit; prioritize remediation into those areas that have the greatest consequences to the whole company and keep rechecking. Assume that you do not have the resources in house to test your security and consider the use of outside consultants to periodically check the strength of your systems and processes. Immediately repair what is found lacking.

GRC is about continuously educating users about threats and how they can be part of the solution, not the problem. Invest in technology to protect your assets. You are responsible for doing your due diligence in finding vendors for services and products that will best protect the interests of your company. Do not delegate your security or product decisions to analysts or audit firms. While they can help, at the end of the day, you are the one who has to live with the purchasing decisions. No one knows all the right answers; consider the use of multiple firms to provide GRC services and products.

"Assume the worst and hope for the best" are the best watchwords of GRC. Bad things will happen every day: machines get infected, employees go rogue and snoop into places they should not, people have money problems and see the company as a source of quick cash, and your competitors have more than enough money to flip an employee to get your secrets. Don't assume that the laws will protect you or your interests: lock up important assets both physically and electronically. Most importantly, always keep auditing and testing.

Visit the following resources for more information about GRC:

About the Author
Philip Lieberman is the founder, president and CEO of Lieberman Software, a leader provider of privileged password management. You can reach him at

Subscribe to
Information Security Today

Powered by VerticalResponse

© Copyright 2009 Auerbach Publications