Leadership Attributes

This is just a place for me to note some of the characteristics of leadership that I want to keep in mind:

• Taking respsonsibility

• Drive to accomplish

• Motivates others

• Committed to objectives 

• Decisive

• Confident 

• Stable

• Empowering

• Enabling

• Developing others

Approaches to Auditing Risk and Control Culture

The July 2013 release of Effective Internal Audit in the Financial Services Sector¹ by the Chartered Institute of Internal Auditors (the Code) calls for Internal Audit to include the risk and control culture of the organisation within its scope.  Noted later in the document is the admission that further work is needed to develop guidance for this area as a less well established set of activities.  I believe that at this time several good sources of guidance do exist to assist auditors in auditing such cultural elements.  As we'll see, much still remains to be done in order for such considerations to be well integrated into regular audit practice and produce meaningful results that add organisational value.  The author intends, however, to point the reader toward some practical approaches that should yield valuable results.
 

Key to auditing anything is an agreed standard of comparison.  The suggestion offered in Effective Internal Audit in the Financial Services Sector, however, that the risk and control culture includes processes, actions and "tone at the top" is not particularly useful in setting such a standard.  The Institute of Internal Auditors produced the International Professional Practices Framework Practice Guide Auditing the Control Environment² in April 2011, which addresses many relevant topics.  Whilst omitting any useful definition of what control culture might be, it does provide audit procedures using seven basic principles that read rather like cultural attributes.  These summarize as:

1. Integrity and ethical values;
2. Importance of [the] Board;
3. Management's philosophy and operating style;
4. Organizational structure;
5. Commitment to competence;
6. Authority and responsibility; and
7. Human resources.

Each of these principles is described with sufficient detail through elements and attributes, control design and control testing considerations, enabling the auditor to see immediate applicability to related risks.  For example, as a foundational element, the Integrity and ethical values principle is supported by the attribute that, "senior management develops a clearly articulated statement of values or ethical behaviours that are understood by key executives and the board."  Several control design features are suggested, including communication of the message that integrity and ethical values cannot be compromised, both through words and actions.  The control tests suggested for consideration go beyond the clichéd survey of employees about the ethical attitudes communicated by management, digging deeper into analysis of the code of conduct content and update process.

Beyond this foundational level, we are directed to consider how the importance of integrity and ethical values is reinforced.  The suggested control design features include multiple modes of internal communications to discuss ethical dilemmas arising in the industry and the manner in which management expects employees to act in such situations.

Similar to the principles recommended in Auditing the Control Environment (2011), the 2013 update to COSO Internal Control - Integrated Framework¹⁰ from the Committee of Sponsoring Organizations of the Treadway Commission provided supplemental guidance in the form of 17 principles of effective internal control.  The thinking behind these principles is discussed at length in Internal Control - Integrated Framework (2013) and in supplemental materials; enough to enable risk managers and auditors to apply them to governance, operations, enterprise risk management and audit functions.  The principles may be used in defining cultural controls and/or serve as guidance in identifying expected controls.  Illustrative elements can then be identified within business frameworks, policies, standards and other guidance.

Auditing the Control Environment (2011) suggests the following criteria for assessing the control environment:

1.  An assessment of the controls included in scope using the organization's standard rating system, together with opportunities for improvement.
2. The assessment of the controls using a defined control maturity model, in addition to the standard rating and opportunities for improvement.
3.  Assessment of controls as directed by the general counsel with a specific objective in mind.
4. Benchmarking between companies and/or between units/departments in the company.

The first suggested criteria, to assess the controls included in scope using the organization's standard rating system, presents several significant challenges for Internal Audit, including:

1.  Assessing the necessity of a given cultural control principle or practice to the mitigation of identified business risks;
2.  Definition of the intended control operation, where formally documented standards or guidance from management may be lacking or elaborated only minimally;
3. Clearly communicating the concerns of Audit over application of abstract principles to stakeholders who are not formally trained in risk management; and
4. Determining the required level of remediation.

Whilst these challenges may be present in many audit projects covering more easily grasped controls, they seem particularly difficult where the controls are inherently "fuzzy" or the means of applying them unclear.  Author proposes that if these challenges can be met, auditors will be able to standardize an audit process that not only meets the requirements of the CIIA Code, but also provides business units with valuable insights concerning the contexts within which they operate; insights that can be used to drive meaningful improvement.

Perhaps even more difficult to assess is the extent or depth to which control implementation should be carried out in order to address relevant risks.  This question is difficult enough for auditors to answer when the controls being considered involve practices that are well understood and standardized within a business area.  It is much more difficult to determine when the concept behind a control and its relevance to the risk might be perceived as abstract.  For example, Auditing the Control Environment (2011) includes 10 paragraphs of description for the Control Design that might be in place to implement the principle of Integrity and Ethical Values.  How many of these design elements are necessary to mitigate the identified risk to be within the defined risk appetite?  The author proposes that the use of maturity models, the second criteria suggested in Auditing the Control Environment (2011) and discussed later in this paper, provide useful metrics to assist management in understanding the current state of implementation for these cultural controls.

Similar to other subjects in various audit projects, one prerequisite for meeting these challenges is to identify the cultural controls that should apply to key risks.  Also implied here is the fact that risks related to potential failures of cultural controls are now recognised as having higher potential impact on the organisation than they were in the past and the need to elevate such risks in audit planning.  If the audit executive takes an approach of evaluating cultural controls as simply additional controls over the kinds of business risks that have traditionally been incorporated in audit projects, then one critical question is whether cultural control 'X' is key to mitigating that risk.  If it is not a key control for mitigation of the identified risk, is it a fit object for audit testing?  The alternative approach, to pursue audits with cultural control or controls environment themes would better highlight IA coverage of these concerns and present the best opportunities to evaluate risk awareness, attitudes and behaviours. It should be expected that performance of dedicated risk culture audits would have the greatest effect in emphasizing to management the importance of these topics.

In attempting to define intended control operation, most organisations will have published various frameworks, standards and guidelines that auditors can reference.  Such resources may include:

• Codes of practice
• Governance manuals
• Risk management policies and/or frameworks

Considering the second criteria specified in Auditing the Control Environment (2011), the author is of the belief there could be significant value in the application of maturity models to the evaluation of cultural controls.  Even where a specific model may not have been adopted by the organisation, IA should consider how such an approach to testing and rating could promote awareness of the importance of cultural controls and enhance reporting of audit findings.  Maturity models are in wide use as a form of business process analysis in many industries and disciplines.  Several examples are easily found that can serve as a useful guide in developing one suitable to your organisation.  The M_o_R, Management of Risk, standard published by Axelos contains a maturity model adapted toward risk management practices.  Author does not have access to this standard, but the definition seems worthy of further investigation.  ISACA's COBIT 4 standard included a maturity model, which has evolved in COBIT 5 into Generic Process Capability Attributes³.  Whilst focused primarily on information technology processes, COBIT maps well to enterprise goals and provides a useful example that could be adapted for more general controls environment evaluations.  Price Waterhouse Cooper has published a maturity model for internal control systems⁴.  Other examples could be cited, but these are not overly complex models and should not be difficult to adapt or utilize.  The Institute of Internal Auditors publication "Selecting, Using, And Creating Maturity Models: A Tool for Assurance And Consulting Engagements," (July 2013) further elaborates on some of these challenges and provides further guidance in this area.

Capability maturity models have a relatively long history of application within information technology process areas, going back to the 1973 publication of Managing the Computer Resource: A Stage Hypothesis⁵ by Richard Nolan.  The concept gained wide adoption and has been adapted to many other business process areas following development of the Capability Maturity Model at the Carnegie Mellon University Software Engineering Institute⁶.  Further examples that may be useful to IA in developing an assessment methodology include the Business Process Maturity Model⁷ and RIMS Risk Maturity Model⁸.

The Business Process Maturity Model (BPMM) is perhaps the most useful example for purposes of this paper, as a standard that is open and widely applicable.  BPMM characterizes processes as meeting one of five maturity levels, defined as:

1.  Level 1: Initial — wherein business processes are performed in inconsistent sometimes ad hoc ways with results that are difficult to predict.
2. Level 2: Managed — wherein management stabilizes the work within local work units to ensure that it can be performed in a repeatable way that satisfies the workgroup’s primary commitments. However, work units performing similar tasks may use different procedures.
3.  Level 3: Standardized — wherein common, standard processes are synthesized from best practices identified in the work groups and tailoring guidelines are provided for supporting different business needs. Standard processes provide an economy of scale and a foundation for learning from common measures and experience.
4. Level 4: Predictable — wherein the capabilities enabled by standard processes are exploited and provided back into the work units. Process performance is managed statistically throughout the workflow to understand and control variation so that process outcomes can be predicted from intermediate states.
5. Level 5: Innovating — wherein both proactive and opportunistic improvement actions seek innovations that can close gaps between the organization’s current capability and the capability required to achieve its business objectives.

A maturity model that is formally adopted and aligned with business goals and risk appetites would provide a ready device not only for IA to use as an assessment tool, but to help further align business practices in diverse areas with the enterprise architecture.

The third criteria suggested by the IIA seems open to definition by general counsel or other organisational stakeholders.  But in the absence of such a request this may not be an approach that IA can readily pursue.  The fourth suggested criteria may also be unsuitable for use in larger, more globalised organisations.  Comparisons between different business units may entail difficulties with obtaining stakeholder buy-in, due to perceived differences in organisational culture.  It may be more applicable in some organisations depending on structure.

As we have seen through this discussion, several resources exist that should assist audit teams to more effectively provide assurance over risk and control culture.  The principles outlined by the Institute of Internal Auditors and COSO may readily be used to identify and define such cultural controls.  Author is of the belief that dedicated audits themed around cultural issues will be most effective at highlighting the importance of such issues.  Additionally, IA should work with business governance and risk management functions to validate maturity models that will be accepted as an additional set of metrics for use in these types of audits.  Such usage will add value to audit products and assist the business to further align employee behaviours, attitudes and promotion of risk awareness with business needs.

References

1. Chartered Institute of Internal Auditors. (2013). Effective Internal Audit in the Financial Services Sector. https://na.theiia.org/standards-guidance/Public%20Documents/Effective%20Internal%20Audit%20Financial%20UK.pdf
2.  Chartered Institute of Internal Auditors. (2011). Auditing the Control Environment. https://na.theiia.org/standards-guidance/Member%20Documents/Auditing_the_Control_Environment.pdf
3.  ISACA. (2012). COBIT 5: A Business Framework for the Governance and Management of Enterprise IT.  http://www.isaca.org/COBIT/Pages/default.aspx
4.  Price Waterhouse Coopers. (2010) "Making sense of internal control: How to align vision, organisation and technology to lower your compliance costs and improve business efficiency." http://www.pwc.ch/user_content/editor/files/publ_ass/pwc_making_sense_of_internal_control_e.pdf?bcsi_scan_11d730a337a869c4=0&bcsi_scan_filename=pwc_making_sense_of_internal_control_e.pdf
5.  Nolan, R. (1973). "Managing the computer resource: a stage hypothesis" in Communications of the ACM, Volume 16 Issue 7, pages 399-405.
6. Humphrey, W. (1988). "Characterizing the software process: a maturity framework" in Software, IEEE, Volume 5, Issue 2, pages 73-79.
7. Object Management Group. (2008). "Business Process Maturity Model" Version 1.0. Retrieved 8 July 2014 from http://www.omg.org/spec/BPMM/1.0/PDF
8. The Risk Management Society (RIMS). RIMS Risk Maturity Model.  Retrieved 8 July 2014 from http://www.rims.org/resources/ERM/Pages/RiskMaturityModel.aspx 
9. COSO. (2013). Internal Control - Integrated Framework. ISBN 978-1-93735-238-7.

SANS GCFE Exam

Just a quick post while waiting on lunch. I'm really psyched about having gotten a very good score on the SANS GIAC Certified Forensic Examiner exam that I just finished. It's a moderately difficult test, but it well reflects the course material. I did the OnDemand FOR408 course and found it to be very well structured and comprehensive. Though SANS Institute has always had some of the most expensive tech training out there, I think this was still an excellent value with all the materials supplied and the  quality of content.

I haven't been able to post as much here as I had hoped as I've been studying for this for months in all my spare time. So, hopefully, I'll be able to post a bit more often.

Information Security 101 for Business Managers

My plan is for this topic to be a running series. I have enough key ideas in mind to provide at least a few posts. The intended audience for these first few will be business managers whose primary focus is not information security, as well as IT Managers  looking for tips to engage with the business and improve how your efforts are targeted.

There are critical areas in your enterprise where business managers can have a bigger impact on information security then the IT team. I'm talking about you, the Manager in Ops or Accounting; even Marketing. Don't tell me Marketing doesn't handle security-sensitive data. I've found your data when I'm doing penetration testing: full copies of customer databases and marketing strategies. And this illustrates my point perfectly; too often management and employees don't think about the sensitivity of their data, haven't thought about how a compromise of data or applications could hurt the business, what level of security is protecting that important data or even where the data is located. This series of posts will attempt to help you solve these issues, protect your business from failure, protect your customers and make yourself look smart.

Principle #1: Know where your stuff is - You have to know where your critical data is stored. You don't need to have the same level of detail on this that IT has, "oh, we've mapped your volume to such and such virtual drive on storage array X." No, you just need some label that will enable you to discuss things meaningfully with IT; something like, "S: drive in the Customer-Service\AppData folder". Don't just tell me, "everything is on our S: drive." Because that contains 10,000 folders, most of which have little business criticality. We don't want to manage it all to the same extent, because it's a waste of expensive IT labor. Whenever an organization tells me that they apply strong protection to all their data, I know right away that they have no idea what they're talking about and I'm likely to find weak controls in place. If you know you have data in a database, list out what server it's on. Maybe the server manages multiple databases, so be specific. Which database is it in? Maybe you can get down to listing specific data tables within the database, but that's difficult and not required at this point.

Note that I said, "You have to know where your critical data is stored." This means that part of your assignment will be to identify what data is critical to your business processes. I'm assuming here that you can define what processes are critical to your business. It sounds easier than it may be in practice. One can definitely be way too granular in listing those out or not granular enough. One hint, you probably have two to six business processes in your department, not 15 (YMMV). If you get stuck on this one, reach out to me and we'll get you some help.  What we're doing is classifying your data.  There are probably templates you can find for policies or procedures on this.  I'll try to cover more in a later post,  but at a basic level, some labels to consider might be "confidential", "sensitive" and "general".  Some organizations get pretty specific with this part of the exercise; others stop at these three categories.  Look to see if your organization already has a data classification policy or procedure.

Another useful way to approach this is to look at your critical software applications. You may as well, I'm going to ask you to list them out anyway. Line of business applications, it goes without saying, are automatically on the list.  Usually we're not concerned with things like Word or Acrobat, but maybe they could be critical to you. Normally we're concerned with applications that store or transform data or communicate that data to clients and business partners. Spreadsheets are a good candidate; anything that accesses or stores stuff in a database or connects to some other system through a network. Internet Explorer would not count, but a business portal web site that you access with the web browser might. We really need to know all such applications that process, store or transmit critical information. Even if it doesn't seem like a critical application, it's important to list it out at this point. You should be able to see where this becomes useful as we delve more into risk assessment in later posts.

One question that might come up is, what do we define as critical?  That's an easy one.  Which kinds of data come to mind when we talk about:

• Unauthorized disclosure to people who shouldn't see it;
• Bad things would happen if the data got corrupted or modified without authorization; or
• We have to have that data or application or web site available to be able to perform business functions or provide services.

We call these business impacts and they all relate to some kind of cost.  Those costs might be in terms of dollars that you can quantify, but it might be less tangible things like loss of reputation or market advantage.

By now you should be asking why we're getting into all these details; after all, don't we normally leave all this technical stuff to the IT guys, the security team or maybe risk management? Unfortunately, most of the time those guys don't really know much detail about everything that you do, how your business processes really function or which bits of data are important.  Sure, they know in a general way, but if they're going to provide assurance for your business processes they need to know in more detail and you have to have it clear in your head in order to be able to communicate it.  Also, and this is huge, you have to tell IT and Security how they should be protecting your applications and data and you can't really do that in a meaningful way if you don't know where it all is or haven't even classified it.  On their own, they would either lock it down so tightly you can't work or, more likely, leave things far too open because they don't know your workflow, your application screens, what might create conflicts of interest, etc, etc.

Next, you need to map out where all these applications live; you'll need to know the names and IP addresses of the servers that they run on.  This is about as deep into technical detail as we're going to get for now, so don't worry that I'm going to tell you to master a bunch of techno-babble.  You don't need to know what an IP address is or what it's used for.  It's just some piece of information to help you track the systems that your data and applications rely on.  This will become more important in later posts as I getting into discussing things like how to turn this information into a risk assessment that just might save your business and your career.  For now, just collect the server names and IP addresses and put it in a chart with your application names and critical data categories.

Update:
This can all be captured in a simple spreadsheet.  To summarize, that spreadsheet should have a column for Application Name, Data Classification Label, Host Name (host means "server" in most cases, but allows for other possibilities too), Host IP Address, Storage Location (folder or database name, e.g. "db: sales").  I've gone a little further with this and developed a System Characterization Worksheet for use in past risk assessment consulting engagements.  You can grab a copy from the Downloads page (see tabs at the top).  I created it for a previous employeer, Info@Risk (http://www.infoatrisk.com), who was kind enough to allow me to publish it under the Creative Commons.  I'll give some further instruction for its use in an upcoming post.  In general, its purpose is to document everything relevant for the risks inherent with a particular system or class of systems and the security measures applied for mitigation.  Business process owners, department managers, can begin using it to capture the information discussed in this post and have IT and Security staff complete the parts that fall under their expertise.

So, whether you are a business manager concerned about whether or not IT is giving you adequate support and security or you are the IT Manager hoping to increase engagement with the business folks, hopefully, these topics will be able to get you started on some conversations.

This was all I had in mind to cover for this post.  In upcoming posts I will be expanding on the ideas covered here and providing more tools to make this more useful.

Constructive comments or questions are welcome.  Good luck to you.