Bridging the Gap

January 4, 2012

Technology and computers are everywhere today, being used across generations, understood by billions of people but yet seem too often to ‘fail’ in business. I can’t count how many dysfunctional relationships I have seen so far in my career as a technology auditor and security consultant (maybe nature of the job). I have worked with the leading corporations of the world to the, still around after 20 years, ‘homegrown’ start ups. The biggest story communicated to me seems to be how IT is always delayed and there seems to be an outage every week; while business has no understanding for technology services and gives IT no budge or planning to work.

Companies need to find a way to break down the silos between departments, operations and staff in developing a secure technology environment. There are many ways to achieve smooth operations between a business group and IT, no matter the history of the company. A good place to start is by coming together in understanding the risk the company faces in today’s global world where business data is ‘online’ for a uncountable amount of entities at any time. Depending on your business’s internal knowledge and staffing, a effective way to understand business risk is by reaching out to a trusted security consulting firm that provides a range of risk advisory services.

The organizations that I have seen benefit the most in mitigating their IT risks and accomplishing more than compliance requirements achieve this by bringing in a experienced team of fresh eyes that have a history in security and compliance consulting. The first thing a good consultant will do is gain an understanding of requirements of the business, assess IT operations and design as well as facilitate general security practices across the organizations. The most efficient organizations are able to bridge the gap between business and technology operations in understanding risk in IT business resulting in a more secure operations where, if necessary, security exceptions are fully communicated, understood and accepted by the business.


First Impressions

December 5, 2011

First impressions do count.  We’re told over and over how important it is to leave a good first impression.  That applies not only to your business and personal relationships but to your PCI-DSS (Payment Card Industry – Data Security Standard) Assessment as well.  While organizations often feel that a PCI Audit does not commence until the kickoff meeting has taken place onsite, the fact is, that the support one receives  prior to the onsite assessment sets the tone.

The QSA notices when stakeholders have to postpone or cancel a meeting without designating someone to attend in their place.  Are they taking this seriously?  The QSA also notices when someone is more adept at challenging the assessment as opposed to wanting to understand the intent.  Unfortunately, in those real world examples the tone has been set.  What makes a successful and productive PCI DSS Assessment is the cooperation and willingness of the organization to complete the PCI Audit in a timely fashion.

The QSA also has a responsibility to ensure the timely completion of the PCI assessment.  How is this accomplished?  By observing current procedures in place that are relevant to the PCI Audit without having to specifically setup a meeting.  By working in the background, much as a process does on your workstation, we can limit the disruption to your company’s normal business operations.

For example, companies often assume that the PCI assessment doesn’t start until all stakeholders have met and exchanged introductions during the kick off meeting.  However, a well trained QSA starts the assessment the moment he or she showed up at your location.

Is an access card required to enter the facility?  Where are the security cameras?  Why wasn’t I challenged when I pressed the intercom to gain access to the facility?   The receptionist might be pleasant but why wasn’t I asked for identification before being issued a badge?  Once issued, why wasn’t I asked to sign into a log?  Why was I buzzed into a secure area without an escort?  A review of Requirement 9 covering Physical Security will show you that a number of requirements were tested prior to our kickoff meeting taking place.  Like a process running in the background, requirements were tested by the QSA without a meeting to all physical security elements.  Since the requirements were already tested and the results well known, they become points for further discussion  throughout the week.

Throughout the documentation review prior to coming on site as well as the moment we step onsite, we’ve already started evaluating compliance and identifying the issues that may keep the PCI Assessment from flowing smoothly.  In the end, first impressions do count.

GRC lessons learned from the Deepwater Horizon oil spill

February 24, 2011

by Gary Alterson

I’m reading the Chief Counsel’s Report issued by the National Commission on the BP Deepwater Horizon Oil Spill released on February 17th.    I’m not finished with the report, but even in the 10 or so pages I’ve read, there’s a treasure trove of “lessons learned” for risk management and GRC professionals.

In addition to detailing the technical decision making errors leading up to the spill, the report highlights several “Overarching Failures of Management” including the following 7 themes:

  1. Ineffective leadership at critical times
  2. Ineffective communication and siloed information
  3. Failure to provide timely procedures
  4. Poor training and supervision of employees
  5. Ineffective management and oversight of contractors
  6. Ineffective use of technology
  7. Failure to appropriately analyze and appreciate risk

The management failures were essentially risk management failures, or poor risk oversight that resulted in a large tail end event – the oil spill.  Some of the key elements identified are symptomatic of issues I’ve observed in the implementation of governance, risk and compliance programs in many organization.  These include:

Unclear accountability

Often times there is an assumed or explicit shared accountability for both the acceptance of risks and decisions made about risk rather than assignment to specific individuals and roles.  In the case of the Deepwater Horizon incident, the Chief Council found confusion over who is accountable for critical decisions, information silos between operations and engineering, resulting in a state where there wasn’t a shared view as to who was accountable for important practices associated with safety and a diffusion of personal responsibility.   There was no explicit accountability assigned for the completion and quality of risk assessments and no one took full management ownership before the blowout.

Lack of clearly defined communication channels

In many cases, it’s assumed communication will happen or the appropriate relationships will just be built as necessary rather than explicitly defining relationships and processes that facilitate communication.  In this case, risks were not clearly communicated by the onshore team to the offshore team performing the drilling.  There was inadequate guidance on when additional expertise or escalation was necessary, and lessons learned from near misses were not actively applied to new or similar situations or even proactively promoted to key decision makers.

Gaps in controls and risk oversight

One of the key benefits of a clear risk and compliance governance program is the provision of management oversight and transparency on to the execution of controls and the risk based decision making of the organization.  In the case of Deepwater Horizon, the report found “significant gaps” in supervision and oversight.  In some cases a single person made critical decisions and performed critical activities without checks – either by supervisors or other companies.

There are lots of lessons to take away from large disasters such as the Deepwater Horizon Oil Spill.  Some of the key ones to apply to your GRC program are:

  • Clearly and explicitly assign accountability to individuals or individual roles within your organization
  • Define clear communication paths and facilitate communication through clear process and procedures
  • Build a robust system oversight onto the decisions being made within your organization organization

Aligning IT Risks to Business – Part Two, Risk Assessment Criteria

February 11, 2011

by Gary Alterson

In my last post, I spoke about the importance of defining a risk universe in helping align your IT risk program in a manner business executives understand.   Another tool to achieve alignment is to define and evaluate risks in a way that is meaningful to your business and provides the intelligence necessary for executives to compare risks and make decisions concerning competing priorities.

In the February 2011 Information Week Analytics Report “Risk Avengers” Erik Bataller and I outline a practical approach to establishing and unlocking the value within an IT Risk Management program.   One of the recommendations, defining common risk criteria, can go a long way to facilitating business decisions concerning risk.

By establishing common multiple equivalent criteria for risk analysis, or a common risk taxonomy, organizations can start to align different risks and build a common language for expressing the relative values of different risks.  In other words, facilitate apples-to-apples comparisons between risks so that your business can appropriately prioritize.

For example, develop  a “catastrophic impact”  category by defining multiple impact type such as regulatory impact (regulator takeover), customer impact (places greater than 25% of customer base at risk), business continuity impact (business interruption of > 5 days), or manufacturing impact (productivity decrease of 15%).    Doing so will allow you to better categorize and compare risks and facilitate more informed business decisions about risk.

Aligning IT Risks to Business – Part One, Risk Universe

February 10, 2011

by Gary Alterson

Many IT risk and information security analysts are at a loss to explain risk to business executives. Part of the reason for this is that they are unable to align their risk terminology to vocabulary that their business leaders understand. However, there is a solution to this problem. In the February 2011 Information Week Analytics Report “Risk Avengers” Erik Bataller and I outline a practical approach to establishing and unlocking the value within an IT Risk Management program. In it we outline the concept of establishing an IT Risk Universe. Establishing a business relevant IT Risk Universe and categorizing your risks according to that universe is one of the key tools to aligning with your executives. All too often we see risk universe categorized along technical silos such as “network vulnerabilities” or “application security”. While useful in helping you assign ownership within IT, this categorization does little to help executives understand those risks. Instead, build categories that help business executives understand how the risk relates to them. Build categories around business impact. At Neohapsis, we’ve built a common risk universe framework around five high level categories. We call this the A5E framework as we build risk universes around 5 top level risks – Alignment, Agility, Accuracy, Availability, Access, and Efficiency. We then build subcategories under this that are relevant to our clients. We’ve found that by building a risk universe that executives understand we can facilitate alignment and communication between our client IT risk and information security staff and their business executives. Defining a risk universe is a great way to evolve your risk program and build in alignment mechanisms that facilitate business understanding and ultimately better decision making.