Sunday, May 28, 2017

C Programming tip: Pass struct pointer to a function as an argument

I'm taking a class in "operating systems" programming this spring, focused on Linux. So, this post may not be much use if you're working in Windows. In my previous assignment we used pthreads to practice multi-threading concepts. One question that came up for me was how to pass multiple arguments to a function called by pthread_create. The answer I kept finding was to pass a pointer to a struct. I had never done that before, wasn't really sure how it was supposed to work and just worked around it in other ways. But in working through my most recent assignment, I decided this was a technique I really wanted to use for the sake of flexibility, even though I wasn't using pthread_create.

The assignment was basically to write a command shell. I won't go into all the details in this post, but just want to stick to passing a struct pointer. The technique works well for pthread_create also.

Step 1: Create a struct with the multiple variables you want to pass as arguments
 25: struct params {  
 26:   int nums[4];  
 27:   char* chPtr;  
 28:   char** argt;  
 29:   char** argu;  
 30: };  

Step 2: Declare an instance of the struct and set some values for your struct member variables
 65: struct params genericParams;
 66: int o;
 67: for(o = 0; o < 4; o++) {
 68:    genericParams.nums[o] = 0;   //initialized to some known value
 69: }
 70: char startDir[512];
 71: memset(startDir, '\0', sizeof(startDir));   //ensure all indices hold the null terminator character
 72: getcwd(startDir, 512);
 73: genericParams.chPtr = startDir;
 74: char* argr[512];
 75: char* args[512];
 76: genericParams.argt = argr;
 77: genericParams.argu = args;

What's going on in this block? After declaring an instance of the struct and initializing the int array to all zeros, I set up a char to hold the path of the current working directory  and store that path in the char (lines 70 - 72). The reason for using memset to initialize all array indices to the null terminator character is to make sure no matter what we put into the array other functions that try to make use of the string will be able to recognize where it ends. If we skip this step we might wind up referencing uninitialized memory, which could hold anything at all.

Line 73 points the chPtr member at the startDir. In this way, we can later read and modify contents of startDir if we want without having to go through a lot of other steps to copy it properly into a struct member.

Lines 74 and 75 declare arrays of pointers to char. We can use each of these array location to hold a separate char*. Remember a char* is one way of representing a string in C.

Lines 76 and 77 point the char** members in our struct at argr and args, giving us a pair of pointers to arrays of char pointers. This provides a lot of flexibility when it comes to manipulating our strings later.

Step 3: Call your function
 163: retVal = childExec(&genericParams);  

By passing &genericParams in our function call, we're really passing the address of the struct instance.

Step 4: Receive the parameters and perform some processing
 433: int childExec(struct params *aStruct) {  
 434:     int o;
 435:     for(o = 0; o < 4; o++) {
 436:         printf("aStruct->nums[%d] = %d\n", o, aStruct->nums[o]);  
 437:     };
     //more code to make use of your other variable members ...
 489: }

Here we receive the address of the struct instance and store it in a pointer, aStruct. Line 436 then just prints the contents of each integer in the nums member array. Since aStruct is a pointer to struct, not itself a struct, we use the -> operator to reference member variables instead of a dot.

That's all there is to this. I hope someone finds it helpful. At least it will serve as a reminder to me on how the heck I did that thing. I will try to follow-up with tips on some of the other techniques I got to make use of in this project. So, do check back.

Tuesday, April 19, 2016

Application Threat Modeling in Risk Management

I presented this topic at West Michigan ISC2 Chapter meeting back in February and have been meaning to get the slide deck posted ever since. My apologies for taking so long with it. I wanted to clean up the references section and needed to add attribution in some places. Life gets in the way sometimes, but anyway.... I hope someone finds it useful. I continue to mine these ideas and the information sources that I cite within the slides.

The central concept is that software is still one of the most insecure areas in any enterprise. We put up firewalls, intrusion detection and prevention systems, implement lovely policies and tell our various boards of directors that we're doing all that can be reasonably done. But how do we know we're really applying the most cost effective mitigations to the right assets? How can we really express to non-technical stakeholders the true levels of risk they are accepting? As security professionals, we know the true picture of security sometimes looks pretty bleak, but we need to do better at quantifying that reality in business terms.

This presentation points to some tools and methods that help us do this. I believe these ideas can help management make more intelligent decisions about what kinds of business services or interfaces they want to offer, build the culture of risk management and the consensus needed to start raising the bar on security.

Download the presentation from the Downloads page, or directly here to get the notes:
or just the slides from SlideShare

Sunday, April 19, 2015

Reasonable Assurance Does Not Make Me Sleep Better

That was the title of a presentation I gave a few days ago at the Lansing Chapter of the Institute of Internal Auditors.  The idea for the theme came to me because I continue to hear the phrase "reasonable assurance" applied in several ways to audit work.  It just struck me that any audit of information technology security performed to a level of reasonable assurance does not make me feel any better about the actual security of the system.

Our adversaries are not "reasonable" in the lengths to which they will go to abuse the systems that we as IT professionals have worked so hard to build. Business customers and citizens interacting with government just want functionality to be able to get a product, a service or communicate with the organization.  But, because that's where the money is, criminals prefer to see these systems and applications as opportunities to steal money or proprietary information, embarrass the organization or bring them down.

If auditors are just trying to ensure that management has done a reasonably good job at implementing reasonable controls that are reasonably effective, we're sunk.  Of course, it's not the job of Audit to identify every vulnerability.  Audit is considered a third line of defense.  Stakeholders might believe Audit has their backs covered, but that's a different problem.  Audit is responsible to ensure stakeholders understand the true risk so that risk can be accepted, mitigated or transferred.  I believe this effort too often fails and I hope this presentation is useful in providing a perspective that may make it easier to achieve that limited goal.

The presentation can be downloaded from the share here:
If you go to my Downloads page, you'll be able to compare the sha1 checksum.

Slide 1 illustration courtesy of artist George Grie, from

Tuesday, January 27, 2015

Big updates to ISC2 CISSP Exam coming soon

The recently announced changes to the ISC2 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:

    Wednesday, January 14, 2015

    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 ISC2 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  Be sure to get the discount and registration codes from the flyer on my downloads page, or directly via:

    Tuesday, September 30, 2014

    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

    Saturday, September 13, 2014

    Approaches to Auditing Risk and Control Culture

    The July 2013 release of Effective Internal Audit in the Financial Services Sector1 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 Environment2 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 Framework10 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 Attributes3.  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 systems4.  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 Hypothesis5 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 Institute6.  Further examples that may be useful to IA in developing an assessment methodology include the Business Process Maturity Model7 and RIMS Risk Maturity Model8.

    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.

    1. Chartered Institute of Internal Auditors. (2013). Effective Internal Audit in the Financial Services Sector.
    2.  Chartered Institute of Internal Auditors. (2011). Auditing the Control Environment.
    3.  ISACA. (2012). COBIT 5: A Business Framework for the Governance and Management of Enterprise IT.
    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."
    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
    8. The Risk Management Society (RIMS). RIMS Risk Maturity Model.  Retrieved 8 July 2014 from 
    9. COSO. (2013). Internal Control - Integrated Framework. ISBN 978-1-93735-238-7.