It has been a few weeks since I’ve posted anything and for that I want to apologize.  I sat down and started a few posts but when I really examined what I wanted to write I realized that I was simply rehashing what has been said on a few other blogs.  Realizing that your time is as valuable as mine I decided not to post anything.  I figured that it was best not to say anything rather than contribute to the noise out there on the Internet. 

 

That is not to say that I haven’t been actively thinking about what I could post that would contribute to the overall body of knowledge.  While I have quite a few ideas, they do not always lend themselves to blog post size snippets (and yes I know I push the limit already.)  Those topics are being redirected into a book that I’m in the process of writing so they will see the light of day eventually.  What I’ve decided to focus on right now though is something that I believe is important and should fit the right length. (more or less)

 

The other night I was having a conversation with a friend.  He was sharing with me his frustration over how security was being ignored and reprioritized by people within his organization.  Now this is nothing new of course as he would readily admit and is something that every information security professional faces all too frequently.  His response was to try to have the security responsibilities for everything reassigned to his group so that the security issues would be addressed.  I think that most of us can identify with that sentiment. 

 

On being asked what I thought, I replied with a question of my own.  “Are you asking me for advice or are you just looking for someone to commiserate with you?”  Not really a fair question I know because there is really only one response but we are close enough friends that I thought I could get away with it.

 

I told him that while I could identify with the desire to “just get the job done” I thought it was a bad idea in the long run.  The reason why is that it transfers the responsibility for security away from the system/information owner and onto the security department. 

 

Now some of you are saying to yourselves “What’s wrong with that?  We’re the experts.  If they are not going to listen to us then we may as well just do the job ourselves.”   Am I right?

 

The problem is that by doing this you are transferring the responsibility for security away from the very people who need to be responsible for it.  By transferring it away the problem now becomes yours and not theirs.  They can say “That’s security’s problem, not mine” and you know something – they’d be right and isn’t that the very thing that caused you to want to take direct control anyway? 

 

Security is everyone’s responsibility.  By transferring the problem away from the system/information owners you are basically telling them that they don’t have to worry about it anymore.  They can carry on with the way they have been going by ignoring security.  In effect you are masking the symptom and not addressing the root cause of the problem. 

 

In order for security to be effective everyone needs to play their part.  Everyone needs to take ownership and do their part to contribute in order to be successful.  I believe that many of the problems that we see today are directly related to the fact that we, without realizing it, have actively divorced people from being responsible for security.  We have transferred responsibility for security to ourselves because we “know better.”  It was easier to do that than to convince others that they needed to change the way the way they do things in order to be secure.  We inadvertently “disengaged” people. As a result when we try to re-engage people we run into resistance.  Subconsciously the reaction is “but that’s not my responsibility, it’s yours.  I have enough to do.”

 

To add insult to injury many of the security awareness and training measures that we have taken to date have only made our jobs more difficult.  Now users, system owners, and information owners can say that they know all about security – they’ve had the training.  Most of them can recite sound security practices when asked.  The problem is that, for the most part, they don’t actually behave that way. 

 

We only perpetuate the problem and reinforce the belief that “security isn’t their responsibility” when we reassign security responsibility to ourselves.  That feeds a negative behavior loop when what we really want to do is break that pattern of behavior.  The only way to do that is to stay the course.  This means that we all become educators, mentors, and coaches in addition to being subject matter experts.  True behavioral changes are the result of both positive and negative reinforcement so find ways to make it beneficial for people to “exercise their security responsibility” and not just punish them when they do something wrong.

 

Now this isn’t the easy answer.  It is analogous to teaching your child how to walk.  In order to do so you need to let them fall down a few times.  You offer encouraging words and put them back on their feet again for another go.  Sooner or later they get the hang of it and off they go.  That doesn’t mean that they are out of the woods.  There will be stubbed toes and running into things every now and then.  If we were to give up and carry our children everywhere then they would never learn and we’d be stuck carrying them everywhere.  That isn’t fair to them or us. 

 

 

 

Tags: ownership, responsibility, who owns security

I received this question the other day:

My CFO and I were discussing compliance with SOX and the GLB the other day and we got into an argument about whether we should be doing security assessments or security audits as the best way of meeting our obligations under these laws.  Can you help me with what I should say about the differences and provide some guidelines on how my company can use these appropriately to meet our compliance requirements?

The lines between auditing and assessing are often blurred.  In the strictest sense, an audit is a measurement of compliance with a standard or a set of criterion and an assessment is a measurement of effectiveness.  Using these strict interpretations, an audit can be looked upon as objective and an assessment can be viewed as subjective. 

Let me place each of these activities into context as perhaps that will shed some light on the differences between the two activities and how they can be blended thus causing the confusion that you experienced with your CFO. 

Audits typically can be imagined as a series of Yes/No or multiple choice questions: “Does the organization….?”  The answers to these questions are designed to highlight areas of non-compliance or gauge how far from compliance an organization is. 

Let us take a look at an example:

“Does the organization have a policy concerning the separation of duties?  Yes/No”

This is a typical audit question.  This question simply asks for the presence of a policy that addresses the separation of duties.  In order to verify this, an auditor would need to see a copy of that policy. 

An assessment would go a bit further and ask to see procedure on how the policy will be implemented and then interview multiple people in order to ascertain if the policy and procedure is being followed.  A judgment is then made concerning how effective the control is (the control being a policy on the separation of duties). 

Audits tend to weight answers to questions in an attempt to also reach some sort of judgment concerning the level of compliance.  Personally, I have an issue with this practice. 

Audits strive to be objective measures.  When the answers to an audit questionnaire are weighted, the auditor is actually making judgments concerning how important certain questions are in the attainment of compliance.  This provides a very subjective foundation to what is suppose to be an objective exercise.  (In my humble opinion of course)

Assessments on the other hand are intended to be subjective and opinionated.  Assessments attempt to place their subject into context.  Referring back to the question above an assessment statement might look something like this:

“Organization XYZ does not have a specific policy on the separation of duties within their network environment.  The organization indicates that funding concerns have limited the size of the network support staff making this control impractical.  In order to compensate, a detailed auditing and review program has been instituted.  Audit logs are reviewed daily and serve as an adequate compensating control.”

The difference between auditing and assessing computer systems is rather clear when using strict definitions of audit and assessment however in practice the line between the two has become blurred.  The benefits of each are often confused thus leading to disagreements such as you experienced with the CFO. 

I prefer to utilize both activities in their strictest sense.  I audit to determine where I am compliance and where I am not compliant.  I also then expand upon these findings to ascertain how well this level of compliance is actually securing the computer system.  I can then make two statements concerning the system: its level of compliance and how effective that level of compliance really is in terms of achieving the goals of the regulation being applied. 

I hope this helps to illustrate the concept.  Please keep those questions coming. 

Tags: assessment, audit, Compliance, measurement

I gave a talk a little while ago about using some of the principles of social psychology when developing and delivering effective security awareness and training programs.  During the talk a member of the audience asked the following question. 

“It seems to me that what you are doing is tricking people into doing what you want.  How is using social psychology any different from what cults do to trick their followers into obeying their rules?”

Now, I certainly do not want to give the impression that I’m advocating some sort of mind control experiment in order to get people to follow corporate policies.  If you will permit me to take a few minutes to explore social psychology (or more specifically: social cogitation), I believe that you will see how this knowledge can be useful in tailoring training programs to be more effective without “brainwashing” the students.

One of the issues with trying to change someone’s behavior is that it is most often done through negative means – punishing bad behavior.  What this does is really just address the symptom rather than the true problem.  Social Cognation is the study of how people process social information, especially its encoding, storage, retrieval, and application to social situations.  In other words, it is the study of how we apply what we know in social situations. 

Social Cognition has five main principles:

• The Power of the Situation over Behavior,
• Blindness for Situational Influences,
• Social Perception and Self-Perception are Constructive Processes,
• Blindness for the Constructed Nature of Social and Self-Perception, and
• Self-Processes are Social.

While a full blown discussion on these topics is well beyond the scope of this short blog post, let me quickly address these and show you how knowledge of these principles can help focus Security Awareness and Training programs to maximize retention without “brainwashing.”

Studies have shown, and I’m sure that you have all experienced it; individuals often act differently in social situations.  Call it peer pressure, group mentality, mob influence; it is all the same thing.  This affect can have both positive and negative influences.  What is more, this influence is typically unnoticed by the individuals experiencing it.  We are often blind to the influence our environment has upon us.  We aim to harness this principle to create an atmosphere, which is conducive to sound information security practices and hopefully by drawing on this principle, gain an increase in policy compliance. 

Perception is the process of acquiring, interpreting, selecting, and organizing sensory information.  Perception is an important influence on the organization of our mind and how we interact with our environment or in other words our perception of the world is constructed by our understanding of abstract concepts.

If our social perception is based on currently activated mental representations, motives, and processes then by introducing and reinforcing new representations and motives we can change the way that information security is perceived.  Of course, again, studies have shown that we, as individuals, are often blind to this process occurring within our minds. 

Finally, studies have shown that individuals base their own self-knowledge much the same way they perceive the world around them.  The understanding of abstract principles that filter an individual’s perception of the world around them also filter the individual’s perception of self.  This really addresses the core problem of information security. 

Information security by its very nature is not social.  We ask you not to allow other individuals to follow you through secure doors, we ask you to be suspicious of emails and unknown files, we ask you to question and report requests for confidential information.  All of these are essentially anti-social behavior and they often run against what we have been taught growing up. 

These concepts are so ingrained into each of us that it takes quite a bit of effort to cause a change in perception.  A program incorporating these concepts seeks to go back to the way that we all learned about the world around us in order to focus on activities that underscore the importance of information security in terms of its benefit to the collective social group.  We wish to show the importance of following these principles in terms of the benefit felt by each of us individually and in turn the benefits felt by the group as a whole.  It turns information security from an anti-social behavior to the truly social behavior that it should be. 

Is this brainwashing?  Well, I certainly don’t think so.  Brainwashing is typically done in such a way that the person being brainwashed doesn’t realize the affect that is occurring.  We are being upfront and honest about our means and our goals. Having an open and honest dialogue about information security within your organization is a healthy and beneficial activity.

Tags: brainwashing, group mentality, mind control, mob influence, peer pressure, perception, security awareness, situation, social cognition, social psychology, training

In part one of this multi-part post, we started out making the case for integrating security into the system development life cycle (SDLC).  In part two we discussed SDLC Methodologies, Key Roles and Responsibilities, and provided an overview of the SDLC phases.  Part Three looked at each of the SDLC phases and highlighted the security considerations of each phase.  In this the fourth and final installment we will wrap everything up. 

As I stated before the paper was written from the assumption that the reader would be unfamiliar with the technical aspects of information security (as is true of most management types – after all that is what they hired us for isn’t it).  My aim was to illustrate information security without being overly technical and thus risk losing my audience.  So without further adieu – A Beginners Guide to Integrating Security into the SDLC Part Four. 

Conclusion

Effective Information Security is security that is incorporated at the onset of a project.  This results in less expensive and more cost effective security.  In order to ensure this, it is important that the roles and responsibilities of all the key players be clearly defined and documented at the onset of any system development project.

When considering developing a system it is important to incorporate security concerns from inception.  This process begins with being able to articulate the security properties desired or required of the system.  These properties need to be based on a comprehensive analysis of the type of information the system is expected to hold.  It is only by considering the criticalities of the information within the system are you able to incorporate appropriate and cost effective security controls.   

Consideration needs to be given to the threats that the system will face once placed into production.  This consideration assists in determining the most effective system configuration in terms of both risk and cost considerations. 

Information Systems are continuously changing and evolving; therefore, operational systems need a robust and security-oriented Configuration Management process.  Each change has the potential of significantly influencing the security posture of the system; therefore, changes need to be evaluated in terms of not only their functional benefit but also the impact the change will have on the security posture. 

Validation and verification testing should be conducted and include all of the security requirements of the system.  These activities should ensure that the security controls established in response to security requirements are included as part of the system development process, and are operating as intended and producing the desired result.

Consideration needs to be given to not only ensuring that the information stored on the system can be retrieved in the future, but that physical media is disposed of properly ensuring that the information contained on this media is rendered unrecoverable prior to disposal. 

Addressing security at the onset of a project ensures that appropriate risk and cost-based decisions are made to balance the operational needs of the company’s systems, but to also ensure the security of the company’s information.  Incorporating security considerations into the SDLC provides the most comprehensive and cost effective approach to ensuring an information system’s viability for both business functionality and information security. 

 

As always I’d be interested in hearing any feedback you may have.  Translating security to management is always a moving target so the more viewpoints that can be incorporated into the approach the better.

Tags: configuration management, information criticality, Key Roles, methodologies, responsibilities, SDLC, System Development Life Cycle, validation and verification

In part one of this multi-part post, we started out making the case for integrating security into the system development life cycle (SDLC).  In part two we discussed SDLC Methodologies, Key Roles and Responsibilities, and provided an overview of the SDLC phases.  In this part we will look at each of the SDLC phases and highlight the security considerations. 

As I stated before the paper was written from the assumption that the reader would be unfamiliar with the technical aspects of information security (as is true of most management types – after all that is what they hired us for isn’t it).  My aim was to illustrate information security without being overly technical and thus risk losing my audience.  So without further adieu – A Beginners Guide to Integrating Security into the SDLC Part Three. 

Security Considerations During the Initiation Phase

The process of Needs Determination is an analytical activity that evaluates the capacity of an organization’s assets to satisfy existing or emerging demands.  Along with establishing a basic system idea, defining preliminary requirements, feasibility and technology assessments, the security considerations of this phase revolve around the development of a high level description of the security controls that need to be integrated and deployed within the system.  These considerations should also address the level of assurance that will be required to ensure the controls are functioning as intended and effective.  These decisions need to be based on a comprehensive analysis of the type of information that the system is expected to hold. 

An initial threat analysis should be conducted to establish the threats that the system will face once placed into production, and should include alternate system architectures and technologies in order to determine the most effective system configuration in terms of both risk and cost considerations. 

Security Considerations during the Acquisition and Development Phase

The Acquisition and Development (A/D) Phase of the SDLC is perhaps the most intensive in terms of security of all the phases.  Many different factors need to be considered and addressed.  This is where the high-level security controls identified in the Initiation Phase are actually integrated into the overall system development.  Some of the following activities should incorporate the security considerations.

• Conducting Market Research on possible solutions
• Conducting a Feasibility Study of identified solutions
• Conducting an Alternate Technologies Analysis to determine if solution is the best technological solution for the need.
• Conducting a Cost Benefits Analysis to determine if the solution is the most cost effective way of meeting the need.
• Developing a targeted Risk Management Plan

The security considerations of neighboring systems should also be addressed to ensure that the system being deployed neither poses a security concern for neighboring system nor inherents security concerns from neighboring systems. 

The new system should

• Not create any new vulnerabilities;
• Not decrease the availability of the other systems;
• Not decrease the overall security posture of the environment;
• Have security specifications that are appropriate for the deployment environment.

The security specifications of the system should clearly state the desired functions and assurances so that the product team and developers can adequately integrate these into development activities.  These security specifications need to be stated in specific terms within the functional requirements. 

Security Considerations during the Implementation Phase

The Implementation stage of the SDLC involves the following activities:

• Installation of the system;
• Inspecting the system to ensure that it was properly installed and performing as expected;
• Acceptance Testing;
• Initial User Training;
• Documentation.

At this stage, independent validation and verification testing should be conducted and include all of the security requirements of the system.  These activities should ensure that the security controls established in response to security requirements are included as part of the system development process, are operating as intended and producing the desired result.

Security Considerations during the Operations and Maintenance Phase

The Operations and Maintenance Phase of the SDLC involves the actual day-to-day operation of the system.  Systems in this phase are continuously changing and evolving; therefore, security needs to be a primary concern within the Configuration Management process.  Each configuration change has the potential of significantly influencing the security posture of the system; therefore, changes need to be evaluated in terms of not only their functional benefit, but also the impact that the change will have on the security posture. 

Security Considerations During the Disposal Phase

The Disposition stage of the SDLC involves the following activities:

• Determining the appropriateness of system disposal;
• Exchange and/or sale of the system hardware;
• Internal Organization screening;
• Transfer and/or Donation of the system.

System disposal activities ensure the orderly termination of the system.  The goal is to preserve the vital information about that system so that some or all of the information may be reactivated in the future if necessary.  Security concerns revolve around information preservation and media sanitization. 

Consideration needs to be given to ensuring that the information stored on the system can be retrieved in the future.  There may be significant legal requirements concerning the retention of information depending upon the type(s) of information the system contains. 

Electronic media often contains residual magnetic or electrical representations of the information contained within the system.  Actions must be performed that render this information unrecoverable prior to the physical media being disposed.  Again, legal requirements may affect the disposal activities. 

Look for the conclusion to this multi-part post next time.  As always I’d be interested in hearing any feedback you may have.  Translating security to management is always a moving target so the more viewpoints that can be incorporated into the approach the better. 

 

References:

National Institute of Standards and Technology, Special Publication 800-64 – Revision 1, Security Considerations in the Information System Development Life Cycle, June 2004

Tags: Acquisition and Development, Disposal, Implementation, Operations and Maintenance, SDLC Phases, System Development Life Cycle