It was probably 1973 or 1974 and I have a vivid memory of sitting in the front seat of my father’s red Pontiac Le Mans while we waited in line for gas.  At the time it must have felt like all day but it was probably only an hour or two.  I’m not sure why I remember this particular time over the other times that we sat in line waiting for gas but I do.  Perhaps it was because I remember the gas station attendant putting something on the back of our car that said something like “last car in line.”

I also remember a lot of talk about alternative energy sources.  At the time I was a child so the technical aspects of alternative energy were probably lost on me but the images of fields of windmills and acres of solar panels did stick in my head.  Everyone was keen on weaning the United States off foreign oil and becoming more self sufficient.  Sound familiar?

That was then and alternative energy issues were on the list of national priorities.  Fast forward twenty years to the mid 1990’s and we fine that alternative energy issues slipped off the list of national priorities.  When we ask ourselves why one of the reasons is that the price of gas had come back down to a reasonable level.  With the fall in gas prices we experienced a reduction in a sense of urgency with regard to fixing the US dependency on foreign oil. 

Fast Forward again to 2007/2008 and the same issues have come up.  The US is still dependent on foreign oil and we have experienced yet another energy crisis.  Not much has changed since the 1970’s in terms of our dependency on others for our energy needs.  Yes technology has improved but the wide scale adoption of alternative energy sources didn’t happen like we thought they would back in the 1970’s. 

As I write this the price of gasoline near me is $1.65 per gallon.  I was paying over $4.00 a gallon not six months ago.  While this is a good think I’m left wondering if history will again repeat itself.

What does all this have to do with Information Risk Management?   Imagine the gas crisis as a security incident.  The incident occurs and after everyone stops scrambling to address the initial aspects of the incident questions start as to how to prevent the incident from happening again.  People become interested in what needs to be done to keep it from happening again.  Everyone is keen to invest the time and money in preventing future attacks but as time goes on the sense of urgency declines.  This is especially true if the incident occurs early in your company’s budget year. 

As the sense of urgency decreases so does the priority that security gets in the budget process.  As we all know, decreased priority in the budget process directly translates to a decrease in funding for security programs.   (A good illustration of this is the behavior loop that I talked about in my posts on the Insider Threat.)  

After the gas crisis of the 70’s, gas prices became low enough that the perception of the risk associated with foreign oil dependence lowered enough that appropriate measures were not taken to ensure that it didn’t happen again.  (Yes I know that the circumstances surrounding the crisis of the 1970’s differed from what we experienced this year but the root issue – foreign dependence remained the same.)  Had we been able to keep the sense of urgency surrounding the alternate energy solutions in the 1970’s would we have had a crisis in 2007/2008?

The key to all of this becomes the problem of how to continue to underscore the need for security so that it is given the appropriate priority when it comes to the budget process.  Trying to do this after the fact can be difficult therefore it is essential that you take the appropriate measure before an incident happens so that you can accurately measure its impact – not only on the information system but on the business it supports. 

In an upcoming post I’ll discuss how to work with business units in developing and implementing the appropriate security measures.

Tags: business impact, gas crisis, security measures, security metrics

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

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 this post we’ll be looking at SDLC Methodologies, Key Roles and Responsibilities, and providing an overview of the SDLC phases. 

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 Duex. 

The SDLC

Many SDLC methodologies exist.  These methodologies, or models, should not be limited within a particular environment, but rather should be dictated by the system under development.  Certain models lend themselves to certain types of systems and can be, in fact, a significant factor in the return-on-investment calculations for certain systems.  While hybrids of various models exist, the following list covers the main model categories, which exist today.

• Linear sequential model
• Prototyping model
• Iterative development models
• Spiral model
• Component assembly model
• Concurrent development model

For illustrative purposes, I will utilize the linear sequential model because of its simplicity; however, the concepts that I’ll cover are applicable to any SDLC Model. 

Key Roles and Responsibilities within the SDLC

It is important to clearly define the roles and responsibilities of all the key players at the onset of any successful project.  While the titles of each role may vary or be combined as appropriate, the delineation of responsibility is important.  It is also vitally important to involve the Information Security department at the onset of the SDLC.  Security concerns and implications should be addressed as early in the process as possible, preferably in the initiation phase, in order to avoid costly and inefficient re-engineering during time critical phases of the SDLC.  

Security Properties

Integrating security into the SDLC begins with being able to articulate the security properties desired within the system.  This process is typically cyclical in refinement beginning at the top level and drilling down into what will eventually be security specifications.  There are many ways to express the high-level security requirements, among them the International Organization for Standardization (ISO) 15408: Common Criteria for Information Technology Common Criteria Security.  Other such high-level requirements exist and should be used as appropriate.

Because the security characteristics of a system evolve over time, the system requirements (including the security requirements) documentation needs to be under configuration management, as is any other system related documentation that evolves over time. 

Phases of the SDLC

 

Each phase of the SDLC aims to achieve specific goals or milestones that must be reached during the systems development.  These are illustrated in Figure 1 and briefly defined below. 

Initiation Phase

• The need for a system is expressed, and the purpose of the system is documented and a cost/benefit analysis is conducted.

Acquisition/Development (A/D) Phase

• The system is designed, purchased, programmed, developed, or otherwise constructed.

Implementation Phase

• The system’s security features are configured and enabled,
• The system is tested and installed, or fielded,
• The system is authorized for processing

Operations/Maintenance (O/M) Phase

• The system performs its intended function.

Disposal Phase

• The system is decommissioned, and its information is either migrated to a new system or sent to archive.

Focusing primarily on the security considerations that need to be incorporated into the SDLC, the following sections will enumerate the appropriate issues. 

 

In Part Three we’ll look at each of the SDLC Phases and review the security considerations of each.

 

And in Part Four we’ll wrap it all up into a conclusion. 

 

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, Common Criteria, Disposal, Implementation, Initiation, Key Roles, methodologies, Operations and Maintenance, Phases of the SDLC, responsibilities, SDLC, Security Properties, System Development Life Cycle

In response to a few inquiries that I’ve gotten I’ve decided to address the basics of how to integrate security into a system development lifecycle (SDLC).  This work was initially part of a paper that I wrote for my Masters program at Norwich University.  I’ve shared the paper with a few clients when the subject has come up and the feedback has been positive enough that I’ve decided to revamp it for posting here. 

 

The paper was written under 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.  The paper was a bit too long to place in one post here so I’ve decided to break it up into a few installments.   So without further adieu – A Beginners Guide to Integrating Security into the SDLC. 

 

Introduction

 

The goals of any company are to deliver a quality product at the lowest reasonable cost and with the highest profit potential.  The emergence of the Internet over the last 30 to 40 years has caused a shift in the typical business model and drastically influenced the way that companies conduct business.   

 

Information Security is really a subset of business risk management, which has been around for centuries.  The protection of information itself has been traced as far back as the Renaissance and double entry bookkeeping as a tool for measuring and controlling corporate assets (1).  As the means of recording and maintaining information evolved over time, so did the methods of controlling information. 

 

Effective Information Security is security that is incorporated at the onset of a project.  If it is included as a requirement early in the system development and/or acquisition process, it typically results in less expensive and more cost effective security.  Waiting to integrate security until later in the process usually results in interoperability issues and increased cost. 

 

 

The purpose of information and information systems is to process, store, transmit, and receive information for individuals and people to use in some form.  In order for this information to be useful, it must be accessible by those individuals who need it, maintain its integrity, and be available when needed.  These objectives are classically referred to as the security triad: confidentiality, integrity, and availability. 

 

 

In order to achieve these objectives, some measure of quality control needs to be enacted to ensure the achievement of these objectives.  Because information systems involve the interaction of people with machines in order to access and interact with the actual information, information security involves human elements as well as technical elements. 

 

Dr. Joseph Juran, a pioneer in quality management, “is recognized as the person who added the human dimension to quality – broadening it from its statistical origins (2).”  Incorporating security as a requirement at the onset of a project is part of the quality control process and must address not only the technical controls employed within systems but also how humans will actually interact with the technology employed.

 

The following sections address the integration of information security concerns within the system development life cycle and how it reduces risks to a manageable level.  Following in the spirit of the Pareto Principle (see Footnote 1), recommendations focus on measures which are both cost effective and risk averse.

 

Footnote1: It was the Italian economist Vilfredo Pareto who, at the beginning of the 20^th Century, observed that 80% of the wealth in Italy was owned and/or controlled by 20% of the population.  While many others also observed similar phenomena, Dr. Joseph Juran, described what he termed as the “vital few and trivial many.”  Dr. Juran was able to identify that typically 20% of the defects cause 80% of the problems in a product.  “The 80/20 Rule” or Pareto’s Principle, as illustrated by Dr. Juran, can be applied during the SDLC to achieve the implementation of quality security controls as well as ensure cost effectiveness.

 

In Part Two we’ll address the Key Roles and Responsibilities within the SDLC, Security Properties, and the Phases of the SDLC. 

 

In Part Three we’ll look at each of the SDLC Phases and review the security considerations of each.

 

And in Part Four we’ll wrap it all up into a conclusion. 

 

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

 

Sources Cited:

 

1 – Bosworth, Seymour. Jacobson, Robert V.  “Brief History and Mission of Information System Security.” Computer Security Handbook, Fourth Edition. Ed. Seymour Bosworth, M. E. Kabay.  New York: Wiley & Sons, 2002.  1-3.

2 – Our Founder: Juran Institute (http://www.juran.com/lower_2.cfm?article_id=21)

Tags: 80/20 Rule, Availability, Business Risk Management, Confidentiality, information security, Integrity, Joseph Juran, MSIA, Norwich University, Pareto Principle, quality control, quality management, risk management, SDLC, Security Objectives, System Development Life Cycle, Vilfredo Pareto