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

This is another question that I have received via email.  As with many questions, there are no generic answers.  My answer is typically “It depends.” So much depends on the organization and its corporate culture.  That said, here is my attempt to generically answer the question. 

As I am sure everyone involved with this discussion will argue, at least on even par with the CIO. I agree with that argument whole-heartedly but the sad reality is that all too often the CSO or Network Security group is an element of the IT department under the CIO. The line of thinking that places us there is that since the devices we oversee are IT assets, that is the most appropriate place for us.

Ideally the CSO should answer directly to the CEO or COO and be on the same level or above the CIO. That said, not many of our colleagues sitting in these positions find themselves so positioned. The trick becomes how to be effective from a disadvantageous position.

Network Security should enable business, not hinder it. Why not leverage this to push our agenda. As an enabler, we need to facilitate change through sound business practices and by becoming the ultimate team player. That does not mean compromising our ethics with regard to security. In my opinion, anyone who finds himself in a position where they need to compromise their ethics probably was ineffective in delivering or framing their argument for security.

A good leader is also a good listener. Listening to the needs of business and formulating ways to meet the business need while being secure is the key to success in the CSO position. Granted, there will be times where we may find ourselves up against roadblocks and we cannot win every battle. An occasional roadblock or defeat can be dealt with but if we are faced with a systematic disregard for security then we need to ask ourselves two questions: Why did the company really create this position and why do I really want to stay here if I am not being effective?

I like beer (bear with me here – I’ll tie back into the topic). I use to have a girlfriend back before I got married who hated beer. While she didn’t have a problem with me having a few cold one’s occasionally, she kept asking me why I liked beer. She just couldn’t understand how anyone could like the taste. I told her that she just hadn’t had a beer she liked yet but that there were hundreds of different varieties. She of course didn’t believe me until I cooked dinner for her one night. At dinner, I served a Raspberry Lambic (beer). She commented on how wonderful the dinner was (I went to Culinary School after college, classically French trained) and how wonderful the Raspberry Champagne was, wherever did I find it. Imagine her astonishment when I told her that it wasn’t champagne but beer.

The point is that my ex-girlfriend thought she didn’t like beer but in reality she just hadn’t tried a beer she liked yet. Information Security is a lot like that.  If you keep serving up the same old beer time and time again when you know that your boss doesn’t like it then you deserve to have it thrown back in your face. By switching tactics and attempting to give your boss something that they think they want and then tell them that not only does it taste good but it something that they thought they didn’t want in the first place will probably be met with a different outcome.

We need to be educators.  We need to deliver our message in such a way that we keep our audience receptive to what we are saying and educate them in why this should be important to them. If we are “organizationally challenged,” that does not mean that we cannot be effective; the job is definitely harder but nothing worthwhile is easy.

Often the org-charts place security where the organization feels it best fits. This is sometimes indicative of the importance the organization places on Information Security (and sometimes it is just where it is without any meaning whatsoever). Our jobs are to change that perception, relate what we do to our business’s mission, and show that by adopting secure practices business, the mission will become more effective.  In short – our jobs are to educate.

Tags: CEO, CIO, CSO, educators, Network Security, organizational structure

A few questions have come in from some readers.  Since some of them are similar I felt that it would be best to answer them here. 

Can anyone really defend themselves against hackers or dishonest insiders? For example, if data leakage is invisible (because there may be no evidence left behind that information has been copied without authorization), how can one possibly defend against it?

Welcome to the Information Age!  Knowledge is power; he who has the knowledge has the power.  Intellectual Assets have become more valuable than physical assets.  The simple text file that contains the formula for a prescription drug could be worth tens of millions.  Individuals, companies, and governments are impacted when their information gets into the wrong hands. 

Information Warfare involves everything from personal identity theft to corporate espionage to offensive attacks against government assets.  The control of information is critical to the new Information Age.  Is it worth the risk interacting with this digital age?  We hear daily about vulnerabilities discovered in the operating systems that we use for work and play.  The applications we trust to hold our data, to view the world with our digital eyes, to pay our bills are fraught with bugs and backdoors.  Our Inboxes are filled with e-mail trying to entice us to provide our personal information.  Malware abounds throughout our interactions.  All around us are threats to our personal information.  With this focus on information, is it truly possible to defend against information warfare attacks when the attacks are just as varied as information warfare itself?

Life is about risk.  We all take risks when we get up in the morning and start our day.  We take risks as we drive our cars.  Our lives involve a mixture of risk avoidance and risk acceptance.  Defending our information against information warfare attacks is also an exercise in risk. 

Can we avoid all information warfare attacks?  No.  Information Systems are too embedded in our lives.  Even were we to hide all our money under our mattresses and never leave the house, the energy we use, the water we drink, the government that provides us services are all provided in some way using information systems.  We cannot avoid all risks therefore, we must decide which risks we can accept and which risks we try to avoid.  We can take efforts to insist that the companies we deal with conduct business securely.  We can petition our government to enforce common sense measures to protect its information systems.  We can ensure that we use good judgment when surfing the Internet. 

It all comes down to levels of acceptable risk.  We need to determine how we go about our lives and conduct business in a way that reduces the level of risk to our information and information systems.  What we cannot reduce or eliminate we must accept.  Much like the Age of Exploration, the Information Age is fraught with pitfalls and unknowns.  The mariners of old stocked their ships with the materials they might need should the unexpected come up.  They did what they could to minimize the impact of unforeseen circumstances and continued onward.  We should take a lesson from them and continue onward.

Tags: backdoors, data leakage, identity theft, Information, information warfare, insiders, risk, SPAM, vulnerabilities