Big updates to ISC2 CISSP Exam coming soon

The recently announced changes to the ISC² CISSP exam are the most significant I've seen in years. They're moving to re-align test coverage to the newest issues in information security and current job practice areas. Some of the previous security domains have been expanded, while others have changed completely or been eliminated.  The new domains are:

Security and Risk Management (Security, Risk, Compliance, Law, Regulations, Business Continuity)

Asset Security (Protecting Security of Assets)

Security Engineering (Engineering and Management of Security)

Communications and Network Security (Designing and Protecting Network Security)

Identity and Access Management (Controlling Access and Managing Identity)

Security Assessment and Testing (Designing, Performing, and Analyzing Security Testing)

Security Operations (Foundational Concepts, Investigations, Incident Management, Disaster Recovery)

Software Development Security (Understanding, Applying, and Enforcing Software Security)

Dr. Eric Cole, author of SANS MGT414, is presenting the new curriculum through the vLive format in early March and other presenters will be field-testing it between now and September 9th when I launch the Mentor sessions in East Lansing, Michigan.

If you saw my earlier post about the Mentor session I'm presenting for the CISSP exam prep, I've updated it to link to the new flyer and registration page.

original post: http://www.redcedarnet.com/2015/01/sans-mentor-information-security.html

SANS Mentor Information Security Training in Mid-Michigan

If you are planning information security training for yourself or employees this year, I hope you'll consider the CISSP® exam preparation course I'm presenting in East Lansing, Michigan, beginning Thursday, March 19 

UPDATE: SANS Institute is in the process of updating the curriculum for this course to align with the changes being announced by ISC² for test candidates beginning April 15, 2015. You want the newest course content that will get you through the new test.  Since we need to move the Lansing Mentor session for this test prep course, the best opening to do it looks like September, starting on Wednesday the 9th.  Hopefully, this means a few more people who were considering the course will be able to register.

If you aren't familiar with the SANS Mentor course format, rather than five days in a lecture, you attend shorter presentations one evening per week.  Bring your questions to class and be prepared for discussion with your peers.  In between sessions you have time to study and digest the materials. You still get all the curriculum you would get at a large SANS conference costing thousands of dollars more, but without the need to take time away from the office.

Details are at http://www.sans.org/event/39467.  Be sure to get the discount and registration codes from the flyer on my downloads page, or directly via: http://goo.gl/vMNW1f

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.

Day 3 at DerbyCon 2013

As I return to trying to write-up my notes on DerbyCon 2013, I'm more amazed than ever at the efforts of Adrian Crenshaw (aka Irongeek) in getting all of the presentations online so fast.  He's already been posting presentations from his next security conference and I'm still just trying to write a few terse thoughts on the presentations that I saw over a week ago.  So, again I want to send out thanks for his contributions in particular, not just at DerbyCon but to the entire infosec community.  Thanks also to the entire staff at the conference.  It wouldn't have been possible without all of you.  Thanks especially to Dave Kennedy, his wife and family for their immense efforts in organizing the Con.  That takes a lot of work across many months.

Sunday was another good day at DerbyCon. Rick (Minga) Redman's presentation on Cracking Corporate Passwords started the day for me.  Intuitively, I think you're right, Rick, auditors should be auditing password quality on a statistical basis.  But, when you talk about going from 85% being easily cracked down to only about 65%, I'm not sure how this is actually going to help stop attackers.  I mean, if I only have passwords for 65 of your users I can still access a lot of stuff and quite possibly, everything that I want.  At best, I think we'll improve our odds of defeating the attacker by a miniscule amount.  In doing pentests, I think on only one engagement was I ever kept away from total ownership of the network by good passwords, and even in that case I got all the data I wanted.  Either way, I highly recommend viewing Rick's presentation.  It's very eye-opening for those of us trying to build good password policies and develop security awareness in our users.

Robert Salgado's talk on SQL injection was another highlight.  He gave a good synopsis on some of the techniques out there and presented quite a few methods I hadn't seen before.  He talked about firewall fuzzing with allowed whitespace characters and showed off the SQL Injection Knowledgebase, which was new to me.

Terry Gold's presentation on physical access control systems was the last big standout for me and came just before the closing ceremonies.  He covered a number of weaknesses in these systems and ways to leverage them for unauthorized access, including brute-forcing of card numbers.  I have a better idea now about the capabilities and differences between low- and high-frequency access cards.  Some other fun tools were shown.

While not as useful to me directly, the talk by Solomon Sonya and Nick Kulesza on the remote administration tool (RAT) they've developed points toward a lot of promise.  It has some really cool features and may be useful to you.

The presentation by Luis Santana on phishing on the tool that he's developed to automate these campaigns was also really good.  PhishPoll is a really nice addition to the pentester's tool set.

You can find all of the videos from these presentations on http://www.derbycon.com by just clicking the YouTube link at the very bottom.  Irongeek also has a good index with abstracts up on his site here: http://www.irongeek.com/i.php?page=videos/derbycon3/mainlist.

Other links to people and things mentioned above include:
http://www.korelogic.com
http://www.websec.ca
http://websec.ca/kb/sql_injection
http://idanalyst.com/

Any links to commercial sites does not imply an endorsement of specific products.  They're just a place to connect with the people that I found interesting and helpful.