Creating an Information Security Program from Scratch

Walter Williams

• Publisher: CRC Press
• Year: 2021
• ISBN:
  9781000449761
• Edition: 1
• Topic: Informatica
• Subtopic: Sicurezza informatica

This book is written for the first security hire in an organization, either an individual moving into this role from within the organization or hired into the role. More and more, organizations are realizing that information security requires a dedicated team with leadership distinct from information technology, and often the people who are placed into those positions have no idea where to start or how to prioritize.

There are many issues competing for their attention, standards that say do this or do that, laws, regulations, customer demands, and no guidance on what is actually effective. This book offers guidance on approaches that work for how you prioritize and build a comprehensive information security program that protects your organization.

While most books targeted at information security professionals explore specific subjects with deep expertise, this book explores the depth and breadth of the field. Instead of exploring a technology such as cloud security or a technique such as risk analysis, this book places those into the larger context of how to meet an organization's needs, how to prioritize, and what success looks like. Guides to the maturation of practice are offered, along with pointers for each topic on where to go for an in-depth exploration of each topic.

Unlike more typical books on information security that advocate a single perspective, this bookexplores competing perspectives withan eye to providing the pros and cons of the different approaches and the implications of choices on implementation and on maturity, as often a choice on an approach needs to change as an organization grows and matures.

1 Getting Started

DOI: 10.1201/9781003093688-1

What is Information Security? What is Cyber Security? How does Cyber Security differ from Information Security? These terms are hotly debated and overused by marketing professionals worldwide. My working definitions are that Information Security is the unification of people following well-defined processes to secure information regardless of location, and that Cyber Security is the same except for a focus on information stored digitally. As I see Cyber Security as a subset of Information Security, I’m going to discuss the larger concept in this volume.

Some see the job of Information Security to guarantee the Confidentiality, Integrity, and Availability of Information, and that these are the core principles of the field. Donn Parker proposed that to this you need to add Utility, Authenticity, and Control. This is now known as the Parkerian Hexad. To this, I believe we need to add Privacy. Anyone who has paid attention to the news in 2020 understands the difference between authenticity and integrity, and when search engines start listing placing car batteries in the ocean as the best way to dispose of them because they’ll now charge electric eels, the lack of authenticity as a potential information security issue becomes apparent. That control is a different issue than confidentiality can be seen from the challenge ransomware poses, as it robs the organization of control of their data. Any individual who has gone to a website to find it is non-responsive understands the difference between utility and availability. Privacy is twofold – the ability to have key information about yourself, and your use of a system kept from others.

Information Security then becomes the part of the organization concerned with organizing people so that they have clearly defined processes which help them protect the confidentiality, integrity, availability, utility, control, authenticity, and privacy of the organization’s information, and the information of the organization’s stakeholders and customers.

Probably the first decision to make is should you start designing your information security program from an analysis of the risks to your organization or build it off of a known compliance framework. This is not an easy decision to make, but it has ramification for both the short- and long-term success of your efforts. The ideal way to do this is to spend a period of time performing an assessment of risk, identify what the risk tolerance is for your organization, and then determine what controls will remediate each risk that is above the threshold which are inexpensive enough to have their costs justified by the reduction of risk.

Even when you’re starting from scratch, you rarely have the time to spend the time doing nothing but performing the needed risk assessment and analysis. If the company has been operating for some time before they hired you, mostly likely have some controls in place already, which may or may not be helpful. The benefit of building an information security program from a compliance framework is that you don’t spend the time in choosing what controls should be put into place, you just follow the road map that others have laid out. The disadvantage of this approach is that if followed too literally, you’ll have checked off the boxes for the framework without ever creating an information security program that supports the goals of your organization.

If your organization processes and/or stores credit cards, you must implement the Payment Card Industry’s (PCI) Data Security Standard (DSS); however, the PCI DSS indicates that your implementation of its recommended controls should be based upon the risk to the business, and that alternative controls may be selected if more appropriate. In other words, some of the standards presume that you’re doing a risk analysis and only implementing controls that remediate specific risks that are untenable to your organization.

This doesn’t mean that you can’t just implement the controls within a specific standard without performing that risk analysis, just that the standards are often encouraging you to do better than that because the authors of the standards know that not every control is appropriate for every organization. In fact, some controls make things worse than better, depending upon the organization and how it operates.

Let me give you a small example of what I mean. In some industries, putting in place a proxy system between your organization and the Internet makes using the Internet safer, as the proxy will filter out use of unapproved sites, but in other industries, it will introduce the risk of loss of key personnel who won’t work in a company that watches their Internet use. A risk analysis helps you know which of the two approaches is more appropriate for your organization. In other words, putting a control into place to remediate one risk causes another. You need to understand which risk fits within the risk tolerance of your organization to make the right decision about what you do, if you decide to implement security through risk management. If you follow security through compliance, you don’t need to worry about making decisions, those have been made for you, so you can implement security controls quickly, however, some of those controls may introduce more risk to your business than what they fix, and you’ll not be aware of this.

The good news is that you can start from either approach. Neither is wrong. Starting with a risk analysis presumes you have time to sort things out before you have to start doing things. Starting with a compliance framework without a risk analysis may mean that you implement controls that do not remediate risk, or introduce risk to the enterprise, but you can always start performing risk analysis and implementing risk management later on in your management cycle and remove controls you’ve discovered introduce more risk than they remediate.

I’m going to look at both starting points and look at the benefits and problems associated with each. Just as there are multiple compliance frameworks, there are multiple methodologies which can be used to analyze and understand risk. Choosing the right methodology is as important a decision as if to start with a risk analysis or with a compliance framework.

There are a number of popular risk analysis methodologies, some of which are closely aligned with particular standards, but all of which can be used across all of the various standards. They all start with the idea that a risk is the probability of an impactful event happening and the degree of the impact to the organization. It is important to keep in mind that a vulnerability is not a risk, but the exploitation of the vulnerability could be a scenario in which a risk event could occur. Jack Jones and Jack Freund like to use the bald tire scenario to illustrate this point. Abstractly a bald tire is a vulnerability, and if the bald tire is on a car being driven, the probability of an impactful event is rather high, however, if the tire is being used as a swing for children, the probability of an impactful event is low. Risk is thus dependent upon the context of the vulnerability. There are multiple scenarios that can transpire from any vulnerability. Keeping with a bald tire, you could simply get a flat, or you could blow out the tire on the highway and crash into another car or into a barrier, or the tire could fly off of the vehicle and hit another. Thus risks could impact your asset (the car), someone else’s asset, (their car) and have multiple impacts (financial in the damage to the vehicle, financial as in medical costs, but also the potential loss of life if the accident is bad enough).

From the above example you can see that a risk can impact an asset that belongs to you, as well as an asset that belongs to others. Identifying risks associated with assets allows ready prioritization, as different assets have different valuations to the enterprise. However, the problem is that the most impactful events may impact assets that are not owned by an organization (the other car in the above example).

It is for this reason that various governmental regulations mandating protection of data that is generally valueless to the organization (such as a driver’s license, or a credit card). While the theft of this data would adversely impact the persons associated with either the driver’s license or credit card number, the organization using these to identify an individual would suffer no financial penalty for the compromise of this data without the fines mandated by these laws instituted to guarantee that organizations would spend the money needed to protect information that isn’t an asset to the organization.

This is one of the potential failures associated with using asset-based risk analysis. You can miss things that could impact your organization. All risk analysis techniques allow for scenario-based risk analysis, and all scenarios involve an understanding of an asset within a context. However, presuming that you know the assets important to an organization sufficiently in order to conduct either a scenario-based risk analysis or an asset-based risk analysis is naive.

It is essential, regardless of the method you are using to perform your analysis, that you spend some time interviewing business stakeholders regarding the assets which they know to be important to their business process. If you, as an example, forget to consider your sales leads in your risk analysis, and those become compromised because you’ve not put into place appropriate controls, you have failed the organization. Sitting down with the business leaders to understand what is important to them is a critical part of any risk analysis; however, the time this takes both from your schedule and theirs is a key reason why you may need to perform a risk analysis for your organization after you’ve already got a controls framework in place.

There are two basic risk analysis techniques, both of which provide a means to decide if you should implement controls that remediate that risks involved. There are what are called qualitative analysis techniques such as Octave, and quantitative approaches such as FAIR. Some techniques produce numerical results without being predictive, taking impact and likelihood and laying them out in a grid or heat map to indicate relative criticality. Other techniques utilize statistical models to estimate probability with the same rigor as used in the Manhattan project. Let’s examine each of the analysis techniques.

Risk Analysis Frameworks

Before I get into the different frameworks, it is important to note that risk analysis is one of the most exciting and changing aspects of information security. The Society of Information Risk Analysts, SIRA, has been active for over ten years and has an annual conference which is both worth attending and rather inexpensive. I highly encourage you to join this organization and to be part of this dynamic and rich community.

OCTAVE

OCTAVE is one of the older asset-based risk assessment approaches. There are three phases to the assessment (Alberts and Dorofee 9):

• Phase 1: Build an Asset-based Threat Profile
• Phase 2: Identify Infrastructure Vulnerabilities
• Phase 3: Develop Security Strategy and Plans

These, ideally, are followed by phases of Implement, Monitor, and Control (Alberts and Dorofee 10). As this methodology is resource intensive, you don’t do a full assessment on all assets, but only on a critical few assets. This implies that your asset identification is associated with a valuation that is universal, and an understanding of impact to an organization in advance of the assessment. OCTAVE assessments must be run by trained assessors who understand how to apply the various worksheets and tools and must understand how business process and technology work together.

The analyst must have a comprehensive knowledge of all security practices of the organization. This makes OCTAVE a problematic approach for an organization just starting out without any controls. This ironically makes OCTAVE a useless risk analysis approach for building an information security program that is risk based, not compliance based. In other words, OCTAVE presumes that something is already being done, even if it is not the right something. Since this matches most organizations, this is not a barrier for implementation.

OCTAVE breaks down the catalog of practices into high-level categories (Alberts and Dorofee 86):

• Strategic Practices:
  • Security Awareness and Training
  • Security Strategy
  • Security Management
  • Security Policy and Regulation
  • Collaborative Security Management
  • Contingency Planning and Disaster Recovery
• Operational Practices:
  • Physical Security
  • Information Technology Security
  • Staff Security
• This is then correlated with various threat profiles, of one of the following types:
  • Human Actors Using Network Access
  • Human Actors Using Physical Access
  • System Problems
  • Other Problems

This is then correlated with a catalog of known vulnerabilities. Three potential sources of this are the CERT Knowledgebase, which can be found at https://kb.cert.org/vuls/, Common Vulnerabilities and Exploits (CVE) which can be accessed at http://cve.mitre.org/, and CAPEC, which can be accessed at https://capec.mitre.org/. The primary difference between CVEs and CAPEC is that CAPEC is a classification of vulnerability types, and CPEs are known and enumerated specific vulnerabilities. You can use either in OCTAVE, however, if you choose to use CVE, your analysis will be out of date very shortly as there are numerous CVE created each day. If, however, you choose to go with CAPEC, your decisions resulting from the analysis may not be specific enough to manage the risk (Alberts and Dorofee 87).

This is one of the many tradeoffs of any analysis, specificity verses relevance. If you choose to use OCTAVE, you’ll want to be certain that your risk reports identify if your analysis is only good looking backwards at the known CVE at the time of the report or is forward looking but imprecise in the specifics of its recommendations by using vulnerability classifications.

Both CVE and CAPEC provide specific advice on the remediation of either the specific vulnerability or the category of vulnerabilities. I prefer a forward-looking risk analysis myself, so I readily use CAPEC over CVEs when I conduct a risk assessment. Many of my peers like the certainty that use of CVEs provide in the remediation steps that must be taken and schedule a fresh assessment of the same risks to the same assets frequently enough to accommodate the changes to new CVEs.

To succeed, OCTAVE risk assessments must be properly scoped, and their results must not be applied outside of the scope of the assessment. This is especially critical if you are using CVEs as an input into the analysis.

OCTAVE depends heavily upon interviewing individuals, starting with senior management, whose participation is viewed as a critical factor in the success. Without their involvement, you can’t identify what they see as the critical business assets that you must protect. The example that was used when I was taught this method was that if the VP of Sales believed his personal rolodex was a critical business asset demanding proper protection, than your analysis must consider this asset and the threats and vulnerabilities associated with it.

Phase I of the OCTAVE assessment would product a list of critical assets, security requirements for those assets, threats to those critical assets, current security practices, and current organizational vulnerabilities (Alberts and Dorofee 81).

Phase II of the OCTAVE assessment looks at the systems involved with the asset, runs a vulnerability analysis against those systems to identify the existing CVE. Ideally this is done with a vulnerability scanner which can produce reports showing the CVE detected. Most modern vulnerability scanners can do this (Alberts and Dorofee 95).

Phase III looks at those vulnerabilities in the context of the assets and produces a report of risks to the critical assets, a measurement of that risk, a protection strategy, and a mitigation plan (Alberts and Dorofee 191).

Octave Allegro (Figure 1.1) is a refinement of the OCTAVE methodology to optimize the use of time and resources. OCTAVE is a very time- and resource-intensive methodology, and the analysis is less important than the decisions that need to be made as a result of the analysis. The primary difference in approach is that OCTAVE presumes that the analysts spend a considerable amount of time interviewing experts to accumulate systemic knowledge. This is needed when the analyst is an external consultant. OCTAVE allegro presumes that the analyst may already have this systemic knowledge of what are imp...