Information Security Principles & Applications

Information Security Principles & Applications
Topic 5: Security Engineering: An Overview 虞慧群

Information Security A successful organization should have multiple layers of security in place: Physical security Personal security Operations security Communications security Network security Information security The protection of information and its critical elements, including systems and hardware that use, store, and transmit that information Necessary tools: policy, awareness, training, education, technology What Is Security? In general, security is “the quality or state of being secure--to be free from danger.” It means to be protected from adversaries--from those who would do harm, intentionally or otherwise. A successful organization should have the following multiple layers of security in place for the protection of its operations: Physical security - to protect the physical items, objects, or areas of an organization from unauthorized access and misuse. Personal security – to protect the individual or group of individuals who are authorized to access the organization and its operations. Operations security – to protect the details of a particular operation or series of activities. Communications security – to protect an organization’s communications media, technology, and content. Network security – to protect networking components, connections, and contents.

NSTISSC Security Model
Policy Storage Processing Transm. Education Confidentiality Technology Integrity Availability

Components of an Information System
Information System (IS) is entire set of software, hardware, data, people, procedures, and networks necessary to use information as a resource in the organization Components Of An Information System To fully understand the importance of information security, it is necessary to briefly review the elements of an information system. An Information System (IS) is much more than computer hardware; it is the entire set of software, hardware, data, people, and procedures necessary to use information as a resource in the organization.

Securing Components Computer can be subject of an attack and/or the object of an attack When the subject of an attack, computer is used as an active tool to conduct attack When the object of an attack, computer is the entity being attacked Securing The Components When considering the security of information systems components, it is important to understand the concept of the computer as the subject of an attack as opposed to the computer as the object of an attack. When a computer is the subject of an attack, it is used as an active tool to conduct the attack. When a computer is the object of an attack, it is the entity being attacked.

It is important to note that the same computer can be both the subject and object of an attack, especially in multi-user systems.

Balancing Information Security and Access
Impossible to obtain perfect security—it is a process, not an absolute Security should be considered balance between protection and availability To achieve balance, level of security must allow reasonable access, yet protect against threats Security And Access Balancing When considering information security, it is important to realize that it is impossible to obtain perfect security. Security is not an absolute; it is a process not a goal. Security should be considered a balance between protection and availability. To achieve balance the level of security must allow reasonable access, yet protect against threats.

This graphic intends to show that tradeoffs between security and access.

The Systems Development Life Cycle
Systems development life cycle (SDLC) is methodology and design for implementation of information security within an organization Methodology is formal approach to problem-solving based on structured sequence of procedures Using a methodology ensures a rigorous process avoids missing steps Goal is creating a comprehensive security posture/program Traditional SDLC consists of six general phases The Systems Development Life Cycle Information security must be managed in a manner similar to any other major system implemented in the organization. The best approach for implementing an information security system in an organization with little or no formal security in place, is to use a variation of the Systems Development Life Cycle (SDLC): the Security Systems Development Life Cycle (SecSDLC). Methodology The SDLC is a methodology for the design and implementation of an information system in an organization. A methodology is a formal approach to solving a problem based on a structured sequence of procedures. Using a methodology ensures a rigorous process, and avoids missing those steps that can lead to compromising the end goal. The goal is creating a comprehensive security posture.

Very much a traditional SDLC diagram.

Investigation What problem is the system being developed to solve?
Objectives, constraints and scope of project are specified Preliminary cost-benefit analysis is developed At the end, feasibility analysis is performed to assesses economic, technical, and behavioral feasibilities of the process Investigation The first phase, investigation, is the most important. What is the problem the system is being developed to solve? This phase begins with an examination of the event or plan that initiates the process. The objectives, constraints and scope of the project are specified. A preliminary cost/benefit analysis is developed to evaluate the perceived benefits and the appropriate levels of cost an organization is willing to expend to obtain those benefits. A feasibility analysis is performed to assesses the economic, technical, and behavioral feasibilities of the process and to ensure that implementation is worth the organization’s time and effort.

Analysis Consists of assessments of the organization, status of current systems, and capability to support proposed systems Analysts determine what new system is expected to do and how it will interact with existing systems Ends with documentation of findings and update of feasibility analysis Analysis The analysis phase begins with the information learned during the investigation phase. This phase consists primarily of assessments of the organization, the status of current systems, and the capability to support the proposed systems. Analysts begin to determine what the new system is expected to do, and how it will interact with existing systems. This phase ends with the documentation of the findings and a feasibility analysis update.

Logical Design Main factor is business need; applications capable of providing needed services are selected Data support and structures capable of providing the needed inputs are identified Technologies to implement physical solution are determined Feasibility analysis performed at the end Logical Design In the logical design phase, the information gained from the analysis phase is used to begin creating a solution system for a business problem. Then, based on the business need, select applications capable of providing needed services. Based on the applications needed, select data support and structures capable of providing the needed inputs. Finally, based on all of the above, select specific technologies to implement the physical solution. In the end, another feasibility analysis is performed.

Physical Design Technologies to support the alternatives identified and evaluated in the logical design are selected Components evaluated on make-or-buy decision Feasibility analysis performed; entire solution presented to end-user representatives for approval Physical Design During the physical design phase, specific technologies are selected to support the alternatives identified and evaluated in the logical design. The selected components are evaluated based on a make-or-buy decision (develop in-house or purchase from a vendor). Final designs integrate various components and technologies. After yet another feasibility analysis, the entire solution is presented to the end-user representatives for approval.

Implementation Needed software created; components ordered, received, assembled, and tested Users trained and documentation created Feasibility analysis prepared; users presented with system for performance review and acceptance test Implementation In the implementation phase, any needed software is created or purchased Components are ordered, received and tested. Afterwards, users are trained and supporting documentation created. Again a feasibility analysis is prepared, and the users are then presented with the system for a performance review and acceptance test.

Maintenance and Change
Consists of tasks necessary to support and modify system for remainder of its useful life Life cycle continues until the process begins again from the investigation phase When current system can no longer support the organization’s mission, a new project is implemented Maintenance and Change The maintenance and change phase is the longest and most expensive phase of the process. This phase consists of the tasks necessary to support and modify the system for the remainder of its useful life cycle. Even though formal development may conclude during this phase, the life cycle of the project continues until it is determined that the process should begin again from the investigation phase. When the current system can no longer support the changed mission of the organization, the project is terminated and a new project is implemented.

The Security Systems Development Life Cycle
The same phases used in traditional SDLC may be adapted to support specialized implementation of an IS project Identification of specific threats and creating controls to counter them SecSDLC is a coherent program rather than a series of random, seemingly unconnected actions The Security Systems Development Life Cycle The same phases used in the traditional SDLC can be adapted to support the specialized implementation of a security project. The fundamental process is the identification of specific threats and the creation of specific controls to counter those threats. The SecSDLC unifies the process and makes it a coherent program rather than a series of random, seemingly unconnected actions.

Investigation Identifies process, outcomes, goals, and constraints of the project Begins with enterprise information security policy Organizational feasibility analysis is performed Investigation The investigation of the SecSDLC begins with a directive from upper management, dictating the process, outcomes and goals of the project, as well as the constraints placed on the activity. Frequently, this phase begins with a statement of program security policy that outlines the implementation of security. Teams of responsible managers, employees and contractors are organized, problems analyzed, and scope defined, including goals objectives, and constraints not covered in the program policy. Finally, an organizational feasibility analysis is performed to determine whether the organization has the resources and commitment necessary to conduct a successful security analysis and design.

Analysis Documents from investigation phase are studied
Analyzes existing security policies or programs, along with documented current threats and associated controls Includes analysis of relevant legal issues that could impact design of the security solution The risk management task begins Analysis In the analysis phase, the documents from the investigation phase are studied. The development team conducts a preliminary analysis of existing security policies or programs, along with documented current threats and associated controls. This phase also includes an analysis of relevant legal issues that could impact the design of the security solution. The risk management task - identifying, assessing and evaluating the levels of risk facing the organization, also begins in this stage.

An Overview of Risk Management
Know yourself: identify, examine, and understand the information and systems currently in place Know the enemy: identify, examine, and understand threats facing the organization Responsibility of each community of interest within an organization to manage risks that are encountered KNOW OURSELVES First, we must identify, examine, and understand the information, and systems, currently in place. In order to protect our assets, defined here as the information and the systems that use, store, and transmit it, we have to understand everything about the information. Once we have examined these aspects, we can then look at what we are already doing to protect the information and systems from the threats.

The Roles of the Communities of Interest
Information security, management and users, information technology all must work together Management review: Verify completeness/accuracy of asset inventory Review and verify threats as well as controls and mitigation strategies Review cost effectiveness of each control Verify effectiveness of controls deployed Risk management process 1) The first focus of management review is asset inventory. 2) Next the threats and vulnerabilities that have been identified as dangerous to the asset inventory must be reviewed and verified as complete and current, and the potential controls and mitigation strategies should be reviewed for completeness. 3) The cost effectiveness of each control should be reviewed as well, and the decisions about deployment of controls revisited. 4) Further, managers of all levels are accountable on a regular schedule for insuring the ongoing effectiveness of every control deployed.

Risk Identification Assets are targets of various threats and threat agents Risk management involves identifying organization’s assets and identifying threats/vulnerabilities Risk identification begins with identifying organization’s assets and assessing their value Risk Identification A risk management strategy calls on us to “know ourselves” by identifying, classifying, and prioritizing the organization’s information assets. These assets are the targets of various threats and threat agents and our goal is to protect them from these threats. Once we have gone through the process of self-examination, we then move into threat identification. We must assess the circumstances and setting of each information asset. To begin managing the risk from the vulnerabilities, we must identify those vulnerabilities and begin exploring the controls that might be used to manage the risks. We begin the process by identifying and assessing the value of our information assets.

Asset Identification and Valuation
Iterative process; begins with identification of assets, including all elements of an organization’s system (people, procedures, data and information, software, hardware, networking) Assets are then classified and categorized Asset Identification and Valuation This iterative process begins with the identification of assets, including all of the elements of an organization’s system: people, procedures, data and information, software, hardware and networking elements. Then, we classify and categorize the assets adding details as we dig deeper into the analysis.

Table 4-1 - Categorizing Components

Threat Identification
Realistic threats need investigation; unimportant threats are set aside Threat assessment: Which threats present danger to assets? Which threats represent the most danger to information? How much would it cost to recover from attack? Which threat requires greatest expenditure to prevent? Threat Identification Each of these threats identified has the potential to attack any of the assets protected. If we assume every threat can and will attack every information asset, this will quickly become more complex and overwhelm the ability to plan. To make this part of the process manageable, each step in the threat identification and vulnerability identification process is managed separately, and then coordinated at the end of the process.

Vulnerability Identification
Specific avenues threat agents can exploit to attack an information asset are called vulnerabilities Examine how each threat could be perpetrated and list organization’s assets and vulnerabilities Process works best when people with diverse backgrounds within organization work iteratively in a series of brainstorming sessions At end of risk identification process, list of assets and their vulnerabilities is achieved Vulnerability Identification We now face the challenge of reviewing each information asset for each threat it faces and creating a list of the vulnerabilities that remain viable risks to the organizations. Vulnerabilities are specific avenues that threat agents can exploit to attack an information asset.

Risk Assessment Risk assessment evaluates the relative risk for each vulnerability Assigns a risk rating or score to each information asset Risk Assessment We can determine the relative risk for each of the vulnerabilities through a process called risk assessment. Risk assessment assigns a risk rating or score to each specific information asset, useful in gauging the relative risk introduced by each vulnerable information asset and making comparative ratings later in the risk control process.

Valuation of Information Assets
Assign weighted scores for value of each asset; actual number used can vary with needs of organization To be effective, assign values by asking questions: Which threats present danger to assets? Which threats represent the most danger to information? How much would it cost to recover from attack? Which threat requires greatest expenditure to prevent? Finally: which of the above questions for each asset is most important to protection of organization’s information?

Risk Determination For the purpose of relative risk assessment, risk equals: Likelihood of vulnerability occurrence TIMES value (or impact) MINUS percentage risk already controlled PLUS an element of uncertainty Risk Determination For the purpose of relative risk assessment: risk = likelihood of vulnerability occurrence times value (or impact) minus percentage risk already controlled plus an element of uncertainty

Identify Possible Controls
For each threat and associated vulnerabilities that have residual risk, create preliminary list of control ideas Residual risk is risk that remains to information asset even after existing control has been applied Identify Possible Controls For each threat and its associated vulnerabilities that have any residual risk, create a preliminary list of control ideas. Residual risk is the risk that remains to the information asset even after the existing control has been applied.

Access Controls Specifically address admission of a user into a trusted area of organization Types of Access Control Mandatory access controls (MAC): give users and data owners limited control over access to information Nondiscretionary controls: managed by a central authority in organization; can be based on individual’s role (role-based controls) or a specified set of assigned tasks (task-based controls) Discretionary access controls (DAC): implemented at discretion or option of data user Lattice-based access control: variation of MAC; users assigned matrix of authorizations for areas of access Types of Access Controls Discretionary Access Controls (DAC) are implemented at the discretion or option of the data user. Mandatory Access Controls (MACs) - are structured and coordinated with a data classification scheme, and are required. Non-discretionary Controls are those determined by a central authority in the organization and can be based on that individual’s role (Role-Based Controls) or a specified set of duties or tasks the individual is assigned (Task-Based Controls) or can be based on specified lists maintained on subjects or objects.

Documenting the Results of Risk Assessment
Final summary comprised in ranked vulnerability risk worksheet Worksheet details asset, asset impact, vulnerability, vulnerability likelihood, and risk-rating factor Ranked vulnerability risk worksheet is initial working document for next step in risk management process: assessing and controlling risk Documenting Results of Risk Assessment The goal of this process has been to identify the information assets of the organization that have specific vulnerabilities and create a list of them, ranked for focus on those most needing protection first. In preparing this list we have collected and preserved a wealth of factual information about the assets, the threats they face, and the vulnerabilities they experience. We should also have collected some information about the controls that are already in place.

Risk Control Strategies
Once ranked vulnerability risk worksheet complete, must choose one of four strategies to control each risk: Apply safeguards (avoidance) Transfer the risk (transference) Reduce impact (mitigation) Understand consequences and accept risk (acceptance) RISK CONTROL STRATEGIES When organizational management has determined that risks from information security threats are creating a competitive disadvantage, they empower the information technology and information security communities of interest to control the risks. Once the project team for information security development has created the Ranked Vulnerability Worksheet, the team must choose one of four basic strategies to control the risks that result from these vulnerabilities. The four risk strategies guide an organization to: 1. Apply safeguards that eliminate or reduce the remaining uncontrolled risks for the vulnerability (avoidance) 2. Transfer the risk to other areas or to outside entities (transference) 3. Reduce the impact should the vulnerability be exploited (mitigation) 4. Inform themselves of all of the consequences and accept the risk without control or mitigation (acceptance)

Avoidance Attempts to prevent exploitation of the vulnerability
Preferred approach; accomplished through countering threats, removing asset vulnerabilities, limiting asset access, and adding protective safeguards Three common methods of risk avoidance: Application of policy Training and education Applying technology Avoidance Avoidance is the risk control strategy that attempts to prevent the realization or exploitation of the vulnerability. This is the preferred approach, as it seeks to avoid risk in its entirety rather than dealing with it after it has been realized. Avoidance is accomplished through countering threats, removing vulnerabilities in assets, limiting access to assets, and/or adding protective safeguards. The most common methods of avoidance involve three areas of controls, avoidance through application of policy, training and education, and technology.

Transference Control approach that attempts to shift risk to other assets, processes, or organizations If lacking, organization should hire individuals/firms that provide security management and administration expertise Organization may then transfer risk associated with management of complex systems to another organization experienced in dealing with those risks Transference Transference is the control approach that attempts to shift the risk to other assets, other processes, or other organizations. If an organization does not already have quality security management and administration experience, it should hire individuals or firms that provide such expertise. This allows the organization to transfer the risk associated with the management of these complex systems to another organization with established experience in dealing with those risks.

Mitigation Attempts to reduce impact of vulnerability exploitation through planning and preparation Approach includes three types of plans: Incident response plan (IRP) Disaster recovery plan (DRP) Business continuity plan (BCP) Mitigation Mitigation is the control approach that attempts to reduce the impact caused by the exploitation of vulnerability through planning and preparation. This approach includes three types of plans: disaster recovery planning (DRP), business continuity planning (BCP), and incident response planning (IRP). Mitigation begins with the early detection that an attack is in progress. The most common of the mitigation procedures is the disaster recovery plan. The DRP includes the entire spectrum of activities to recover from an incident. The DRP can include strategies to limit losses before and during the disaster. DRPs usually include all preparations for the recovery process, strategies to limit losses during the disaster, and detailed steps to follow when the disaster has ended. The actions an organization can and perhaps should take while the incident is in progress should be defined in a document referred to as the incident response plan or IRP. The IRP provides answers to questions victims might pose in the midst of a disaster. It answers the questions: What do I do NOW?! What should the administrators do first? Who should they contact? What should they document? DRP and IRP planning overlap to a degree. In many regards, the DRP is the subsection of the IRP that covers disastrous events. While some DRP and IRP decisions and actions are the same, their urgency and results can differ dramatically. The DRP focuses more on preparations completed before and actions taken after the incident, while the IRP focuses on intelligence gathering, information analysis, coordinated decision making and urgent, concrete actions. The third type of planning document under mitigation is the business continuity plan or BCP. The BCP is most strategic and long-term plan of the three plans. It encompasses the continuation of business activities if a catastrophic event occurs, such as the loss of an entire database, building or operations center. The BCP includes planning for the steps to insure the continuation of the organization when the scope or scale of a disaster exceeds the DRPs ability to restore operations.

Mitigation (continued)
DRP is most common mitigation procedure The actions to take while incident is in progress is defined in IRP BCP encompasses continuation of business activities if catastrophic event occurs

Acceptance Doing nothing to protect a vulnerability and accepting the outcome of its exploitation Valid only when the particular function, service, information, or asset does not justify cost of protection Risk appetite describes the degree to which organization is willing to accept risk as trade-off to the expense of applying controls Acceptance With the Acceptance control approach, an organization evaluates the risk of a vulnerability and allows the risky state to continue as is. The only acceptance strategy that is recognized as valid occurs when the organization has: Determined the level of risk Assessed the probability of attack Estimated the potential damage that could occur from these attacks Performed a thorough cost benefit analysis Evaluated controls using each appropriate type of feasibility Decided that the particular function, service, information, or asset did not justify the cost of protection Acceptance of risk is the choice to do nothing to protect a vulnerability and to accept the outcome of its exploitation. This control, or rather lack of control, is based on the assumption that it may be a prudent business decision to examine the alternatives and determine that the cost of protecting an asset does not justify the security expenditure. The term, risk appetite is used to describe the degree to which an organization is willing to accept risk as a trade-off to the expense of applying controls.

Characteristics of Secure Information
Controls can be classified according to the characteristics of secure information they are intended to assure These characteristics include: confidentiality; integrity; availability; authentication; authorization; accountability; privacy Information Security Principle Controls operate within one or more of the commonly accepted information security principles: Confidentiality Integrity Availability Authentication Authorization Accountability Privacy

Feasibility Studies Before deciding on strategy, all information about economic/non-economic consequences of vulnerability of information asset must be explored A number of ways exist to determine advantage of a specific control Feasibility Studies and the Cost Benefit Analysis Before deciding on the strategy for a specific vulnerability all information about the economic and non-economic consequences of the vulnerability facing the information asset must be explored. Fundamentally we are asking, “What are the actual and perceived advantages of implementing a control contrasted with the actual and perceived disadvantages of implementing the control?”

Cost Benefit Analysis (CBA)
Most common approach for information security controls is economic feasibility of implementation CBA is begun by evaluating worth of assets to be protected and the loss in value if those assets are compromised The formal process to document this is called cost benefit analysis or economic feasibility study Cost Benefit Analysis (CBA) The approach most commonly considered for a project of information security controls and safeguards is the economic feasibility of implementation. An organization begins by evaluating the worth of the information assets to be protected and the loss in value if those information assets are compromised by the specific vulnerability. It is only common sense that an organization should not spend more to protect an asset than it is worth. The formal process to document this is called a cost benefit analysis or an economic feasibility study.

Cost Benefit Analysis (CBA) (continued)
Items that impact cost of a control or safeguard include: cost of development; training fees; implementation cost; service costs; cost of maintenance Benefit is the value an organization realizes by using controls to prevent losses associated with a vulnerability Asset valuation is process of assigning financial value or worth to each information asset; there are many components to asset valuation CBA: Factors Some of the items that impact the cost of a control or safeguard include: Cost of development or acquisition Training fees Cost of implementation Service costs Cost of maintenance

Cost Benefit Analysis (CBA) (continued)
Once worth of various assets is estimated, potential loss from exploitation of vulnerability is examined Process results in estimate of potential loss per risk Expected loss per risk stated in the following equation: Annualized loss expectancy (ALE) equals Single loss expectancy (SLE) TIMES Annualized rate of occurrence (ARO) SLE is equal to asset value times exposure factor (EF) CBA: Loss Estimates Once an organization has estimated the worth of various assets, it can begin to examine the potential loss that could occur from the exploitation of vulnerability or a threat occurrence. This process results in the estimate of potential loss per risk. The questions that must be asked here include: What damage could occur, and what financial impact would it have? What would it cost to recover from the attack, in addition to the costs from #1? What is the single loss expectancy for each risk?

The Cost Benefit Analysis (CBA) Formula
CBA determines whether or not control alternative being evaluated is worth cost incurred to control vulnerability CBA most easily calculated using ALE from earlier assessments, before implementation of proposed control: CBA = ALE(prior) – ALE(post) – ACS ALE(prior) is annualized loss expectancy of risk before implementation of control ALE(post) is estimated ALE based on control being in place for a period of time ACS is the annualized cost of the safeguard CBA: Formula In its simplest definition, CBA is whether or not the control alternative being evaluated is worth the associated cost incurred to control the specific vulnerability. While many CBA techniques exist, for our purposes, the CBA is most easily calculated using the ALE from earlier assessments. CBA = ALE(prior) – ALE(post) – ACS ALE prior is the Annualized Loss Expectancy of the risk before the implementation of the control. ALE post is the ALE examined after the control has been in place for a period of time. ACS is the Annual Cost of the Safeguard.

Benchmarking An alternative approach to risk management
Benchmarking is process of seeking out and studying practices in other organizations that one’s own organization desires to duplicate One of two measures typically used to compare practices: Metrics-based measures Process-based measures Benchmarking An alternative strategy to the cost benefit analysis and its attempt to place a hard dollar figure on each information asset is to approach risk management from a different angle. Instead of determining the financial value of information, and then implementing security as an acceptable percentage of that value, an organization could look at peer institutions to determine what others are doing to protect their information (benchmarking). Benchmarking is the process of seeking out and studying the practices used in other organizations that produce the results you desire in your organization. When benchmarking, an organization typically uses one of two measures to compare practices, to determine which practices it would prefer to implement. These are metrics-based measures, and process-based measures. Metrics-based measures are comparisons based on numerical standards, such as: Numbers of successful attacks Staff-hours spent on systems protection Dollars spent on protection Numbers of security personnel Estimated losses in dollars of information due to successful attacks Loss in productivity hours associated with successful attacks An organization uses this information by ranking competitive businesses within a similar size or market, and determining how their measures compare to others. Process-based measures are generally less number-focused and more strategic than metrics-based measures. For each of the areas the organization is interested in benchmarking, process-based measures enable the companies to examine the activities an individual company performs in pursuit of its goal, rather than the specifics of how goals were attained. The primary focus is the method the organization uses to accomplish a particular process, rather than the outcome. In information security, two categories of benchmarks are used: standards of due care/due diligence, and best practices. Within best practices is a sub-category of practices referred to as the gold standard, those practices typically viewed as “the best of the best.”

Benchmarking (continued)
Standard of due care: when adopting levels of security for a legal defense, organization shows it has done what any prudent organization would do in similar circumstances Due diligence: demonstration that organization is diligent in ensuring that implemented standards continue to provide required level of protection Failure to support standard of due care or due diligence can leave organization open to legal liability Due Care/Due Diligence When organizations adopt levels of security for a legal defense, they may need to show that they have done what any prudent organization would do in similar circumstances. This is referred to as a standard of due care. It is insufficient to just implement these standards and then ignore them. The application of controls at or above the prescribed levels and the maintenance of those standards of due care show that the organization has performed due diligence. Due diligence is the demonstration that the organization is diligent in ensuring that the implemented standards continue to provide the required level of protection. Failure to support a standard of due care or due diligence can open an organization to legal liability, provided it can be shown that the organization was negligent in its application or lack of application of information protection.

Benchmarking (continued)
Best business practices: security efforts that provide a superior level protection of information When considering best practices for adoption in an organization, consider: Does organization resemble identified target with best practice? Are resources at hand similar? Is organization in a similar threat environment? Best Business Practices Security efforts that seek to provide a superior level of performance in the protection of information are referred to as best business practices or simply best practices or recommended practices. Best security practices (BSPs) are those security efforts that are among the best in the industry, balancing the need to access with the need to provide adequate protection. Best practices seek to provide as much security as possible for information and systems while maintaining a solid degree of fiscal responsibility. When considering best practices for adoption in your organization, consider the following: Does your organization resemble the identified target organization of the best practice? Are the resources you can expend similar to those identified in the best practice? A best practice proposal that assumes unlimited funding and does not identify needed tradeoffs will be of limited value if your approach has strict resource limits. Are you in a similar threat environment as that proposed in the best practice? A proposal of best practice from months and even weeks ago may not be appropriate for the current threat environment.

Problems with Benchmarking and Best Practices
Organizations don’t talk to each other (biggest problem) No two organizations are identical Best practices are a moving target Knowing what was going on in information security industry in recent years through benchmarking doesn’t necessarily prepare for what’s next Problems with benchmarking and best practices The biggest problem with benchmarking in information security is that organizations don’t talk to each other. Another problem with benchmarking is that no two organizations are identical. A third problem is that best practices are a moving target. What worked well two years ago may be completely worthless against today’s threats. One last issue to consider is that simply knowing what was going on a few years ago, as in benchmarking, doesn’t necessarily tell us what to do next.

Risk Management Discussion Points
Organizations must define level of risk it can live with Risk appetite: defines quantity and nature of risk that organizations are willing to accept as tradeoffs between perfect security and unlimited accessibility are weighed Residual risk: risk that has not been completely removed, shifted, or planned for Risk Management Discussion Points Not every organization has the collective will to manage each vulnerability through the application of controls. Depending on the willingness to assume risk, each organization must define its risk appetite. Risk appetite defines the quantity and nature of risk that organizations are willing to accept as they evaluate the tradeoffs between perfect security and unlimited accessibility.

Logical Design Creates and develops blueprints for information security Incident response actions planned: Continuity planning Incident response Disaster recovery Feasibility analysis to determine whether project should continue or be outsourced Logical Design The logical design phase creates and develops the blueprints for security, and examines and implements key policies that influence later decisions. Also at this stage, critical planning is developed for incident response actions to be taken in the event of partial or catastrophic loss. Next, a feasibility analysis determines whether or not the project should continue or should be outsourced. Physical Design In the physical design phase, the security technology needed to support the blueprint outlined in the logical design is evaluated, alternative solutions generated, and a final design agreed upon. The security blueprint may be revisited to keep it synchronized with the changes needed when the physical design is completed. Criteria needed to determine the definition of successful solutions is also prepared during this phase. Included at this time are the designs for physical security measures to support the proposed technological solutions. At the end of this phase, a feasibility study should determine the readiness of the organization for the proposed project, and then the champion and users are presented with the design. At this time, all parties involved have a chance to approve the project before implementation begins.

Hybrid Framework for a Blueprint of an Information Security System
Result of a detailed analysis of components of all documents, standards, and Web-based information described previously Offered here as a balanced introductory blueprint for learning the blueprint development process Hybrid Framework for a Blueprint of an Information Security System The framework proposed is the result of a detailed analysis of the components of all the documents, standards, and Web-based information described in the previous sections. It is offered to the student of information security as a balanced introductory blueprint for learning the blueprint development process.

Figure 5-15 – Spheres of Security
Figure 6-16, showing the sphere of security, is the foundation of the security framework. Generally speaking, the sphere of security represents the fact that information is under attack from a variety of sources. The sphere of use, at the left of the figure, illustrates the ways in which people can directly access information: for example, people read hard copies of documents; they also access information through systems, such as the electronic storage of information. Information, as the most important asset to security, is illustrated at the core of the sphere. Information is always at risk from attacks through the people and computer systems that have direct access to the information. Networks and the Internet represent indirect threats, as exemplified by the fact that a person attempting to access information from the Internet must first go through the local networks and then access systems that contain the information. The sphere of protection, at the right of the figure, illustrates that between each layer of the sphere of use there must exist a layer of protection to prevent access to the inner layer from the outer layer. Each shaded band is a layer of protection and control. For example, the layer labeled “policy education and training” is located between people and the information. Controls are also implemented between systems and the information, between networks and the computer systems, and between the Internet and internal networks. This reinforces the concept of defense in depth. As illustrated in the sphere of protection portion of Figure 6-16, a variety of controls can be used to protect the information. The list in the figure is not intended to be comprehensive but illustrates individual safeguards that protect the various systems that are located closer to the center of the sphere. However, as people can directly access each ring as well as the information at the core of the model, people require unique approaches to security. In fact, the resource of people must become a layer of security, a human firewall that protects the information from unauthorized access and use. The members of the organization must become a safeguard, which is effectively trained, implemented, and maintained, or else they, too, become a threat to the information.

Physical Design The physical design process:
Selects technologies to support information security blueprint Identifies complete technical solutions based on these technologies, including deployment, operations, and maintenance elements, to improve security of environment Designs physical security measures to support technical solution Prepares project plans for implementation phase that follows Physical Design Selects specific technologies to support the information security blueprint Identifies complete technical solutions based on these technologies, including deployment, operations, and maintenance elements, to improve the security of the environment Designs physical security measures to support the technical solution Prepares project plans for the implementation phase that follows

Implementation SecSDLC implementation phase accomplished through changing configuration and operation of organization’s information systems Implementation includes changes to procedures, people, hardware, software, and data Organization translates blueprint for information security into a concrete project plan Organization should avoid overconfidence after implementation of improved information security profile as time passes by Implementation The implementation phase is similar to the traditional SDLC. The security solutions are acquired (made or bought), tested, and implemented, and tested again. Personnel issues are evaluated and specific training and education programs conducted. Finally, the entire tested package is presented to upper management for final approval.

Project Management for Information Security
Once organization’s vision and objectives are understood, process for creating project plan can be defined Major steps in executing project plan are: Planning the project Supervising tasks and action steps Wrapping up Each organization must determine its own project management methodology for IT and information security projects Project Management In the Implementation Phase Once the organization’s vision and objectives are documented and understood, the processes for translating the blueprint into a project plan can be defined. Organizational change is not easily accomplished. The major steps in executing the project plan are: Planning the project Supervising tasks and action steps within the project plan Wrapping up the project plan The project plan can be developed in any number of ways. Each organization has to determine its own project management methodology for IT and information security projects. Whenever possible, information security projects should follow the organizational practices of project management. If your organization does not have clearly defined project management practices, the following general guidelines on project management practices can be applied.

Developing the Project Plan
Creation of project plan can be done using work breakdown structure (WBS) Major project tasks in WBS are work to be accomplished; individuals assigned; start and end dates; amount of effort required; estimated capital and noncapital expenses; and identification of dependencies between/among tasks Each major WBS task further divided into smaller tasks or specific action steps Developing the Project Plan Planning for the implementation phase involves the creation of a detailed project plan. The creation of the project plan can be accomplished using a simple planning tool, such as the work breakdown structure (WBS). Common task attributes are: Work to be accomplished (activities and deliverables) Individuals (or skills set) assigned to perform the task Start and end dates for the task (when known) Amount of effort required for completion in hours or work days Estimated capital expenses for the task Estimated non-capital expenses for the task Other tasks on which the task depends Each major task is then further divided into either smaller tasks or specific action steps. Key components of the project plan are: Identify Work To Be Accomplished. Describe the skill set or individual person needed to accomplish the task. Focus on determining only completion dates for major milestones. Estimate the expected capital expenses for the completion of this task, subtask, or action item. Estimate the expected non-capital expenses for the completion of the task, subtask, or action item. Note wherever possible the dependencies of other tasks or action steps on the task or action step at hand.

Project Planning Considerations
As project plan is developed, adding detail is not always straightforward Special considerations include financial; priority; time and schedule; staff; procurement; organizational feasibility; and training Project Planning Considerations As the project plan is developed, adding detail to the plan is not always straightforward. Special considerations include: financial, priority, time, staff, scope, procurement, organizational feasibility, training and indoctrination and change control and technology governance

Executing the Plan Negative feedback ensures project progress is measured periodically Measured results compared against expected results When significant deviation occurs, corrective action taken Often, project manager can adjust one of three parameters for task being corrected: effort and money allocated; scheduling impact; quality or quantity of deliverable Executing the Plan Once a project is underway, it is managed to completion using a process known as a negative feedback loop or cybernetic loop, which ensures that progress is measured periodically. The measured results are compared against expected results. When significant deviation occurs, corrective action is taken to bring the task that is deviating from plan back into compliance with the projection, or else the estimate is revised in light of new information. When corrective action is required, there are two basic situations: either the estimate was flawed or performance has lagged. When an estimate is flawed, for example a faulty estimate for effort hours is discovered, the plan should be corrected and downstream tasks updated to reflect the change. When performance has lagged, for example due to high turnover of skilled employees, correction is required by adding resources, lengthening the schedule, or by reducing the quality or quantity of the deliverable. The decisions are usually expressed in terms of trade-offs. Often a project manager can adjust one of the three planning parameters for the task being corrected: 1. Effort and money allocated 2. Elapsed time or scheduling impact 3. Quality or quantity of the deliverable

Figure 10-1

Project Wrap-up Project wrap-up usually handled as procedural task and assigned to mid-level IT or information security manager Collect documentation, finalize status reports, and deliver final report and presentation at wrap-up meeting Goal of wrap-up to resolve any pending issues, critique overall project effort, and draw conclusions about how to improve process Wrap-up Project wrap-up is usually handled as a procedural task assigned to a mid-level IT or information security manager. These managers collect documentation, finalize status reports, and deliver a final report and a presentation at a wrap-up meeting. The goal of the wrap-up is to resolve any pending issues, critique the overall effort of the project, and draw conclusions about how to improve the process for the future.

Conversion Strategies
As components of new security system are planned, provisions must be made for changeover from previous method of performing task to new method Four basic approaches Direct changeover Phased implementation Pilot implementation Parallel operations Conversion Strategies As the components of the new security system are planned, provisions must be made for the changeover from the previous method of performing a task to the new methods. 1. Direct changeover: Also known as going “cold turkey,” involves stopping the old method and beginning the new. 2. Phase implementation: the most common approach, involves rolling out a piece of the system across the entire organization. 3. Pilot implementation: involves implementing all security improvements in a single office, department, or division, and resolving issues within that group before expanding to the rest of the organization. 4. Parallel operations: involve running the new methods alongside the old methods.

The Maintenance Model Designed to focus organizational effort on maintaining systems Recommended maintenance model based on five subject areas External monitoring Internal monitoring Planning and risk assessment Vulnerability assessment and remediation Readiness and review The Maintenance Model A maintenance model is intended to complement the chosen management model and focus organizational effort on maintenance. This figure diagrams a full maintenance program and forms a framework for the discussion of maintenance that follows. External monitoring Internal monitoring Planning and risk assessment Vulnerability assessment and remediation Readiness and review

Figure 12-1 - The Maintenance Model

Monitoring the External Environment
Objective to provide early awareness of new threats, threat agents, vulnerabilities, and attacks that is needed to mount an effective defense Entails collecting intelligence from data sources and giving that intelligence context and meaning for use by organizational decision makers Monitoring The External Environment The objective of the external monitoring domain within the maintenance model is to provide the early awareness of new and emerging threats, threat agents, vulnerabilities, and attacks that is needed to mount an effective and timely defense. External monitoring entails collecting intelligence from data sources, and then giving that intelligence context and meaning for use by decision makers within the organization.

Monitoring the Internal Environment
Maintain informed awareness of state of organization’s networks, systems, and defenses by maintaining inventory of IT infrastructure and applications Internal monitoring accomplished by: Active participation in, or leadership of, IT governance process Real-time monitoring of IT activity using intrusion detection systems Automated difference detection methods that identify variances introduced to network or system hardware and software Monitoring The Internal Environment It is just as important to monitor the external environment as the internal environment, that is the internal computing environment. The primary goal of the internal monitoring domain is to maintain an informed awareness of the state of all of the organization’s networks, information systems, and information security defenses. Building and maintaining an inventory of network devices and channels, IT infrastructure and applications, and information security infrastructure elements Active participation in, or leadership of, the IT governance process within the organization to integrate the inevitable changes found in all network, IT, and information security programs Real-time monitoring of IT activity using intrusion detection systems to detect and initiate responses to specific actions or trends of events that introduce risk to the organization’s assets Periodic monitoring of the internal state of the organization’s networks and systems. This recursive review of the network and system devices that are inline at any given moment and any changes to the services offered on the network is needed to maintain awareness of new and emerging threats. This can be accomplished through automated difference detection methods that identify variances introduced to the network or system hardware and software.

Planning and Risk Assessment
Primary objective to keep lookout over entire information security program Accomplished by identifying and planning ongoing information security activities that further reduce risk Planning And Risk Assessment The primary objective of the planning and risk assessment domain is to keep an eye on the entire information security program. This is done in part by identifying and planning ongoing information security activities that further reduce risk. Also, the risk assessment group identifies and documents risks introduced by both IT projects and information security projects. Further, it identifies and documents risks that may be latent in the present environment. The primary outcomes from this domain are: Establishing a formal information security program review process that complements and supports both the IT planning process and strategic planning processes Instituting formal project identification, selection, planning and management processes for information security follow-on activities that augment the current program Coordinating with IT project teams to introduce risk assessment and review for all IT projects, so that risks introduced from the introduction of IT projects are identified, documented, and factored into projects decisions. Integrating a mindset of risk assessment across the organization to encourage the performance of risk assessment activities when any technology system is implemented or modified

Planning and Risk Assessment (continued)
Primary outcomes Establishing a formal information security program review Instituting formal project identification, selection, planning and management processes Coordinating with IT project teams to introduce risk assessment and review for all IT projects Integrating a mindset of risk assessment across organization

Vulnerability Assessment and Remediation
Primary goal is identification of specific, documented vulnerabilities and their timely remediation Accomplished by: Using vulnerability assessment procedures Documenting background information and providing tested remediation procedures for reported vulnerabilities Tracking vulnerabilities from when they are identified Communicating vulnerability information to owners of vulnerable systems Vulnerability Assessment And Remediation The primary goal of the vulnerability assessment and remediation domain is the identification of specific, documented vulnerabilities and their timely remediation. This is accomplished by: Using vulnerability assessment procedures which are documented to safely collect intelligence about network, platforms, dial-in modems, and wireless network systems Documenting background information and providing tested remediation procedures for the reported vulnerabilities Tracking, communicating, reporting and escalating to management the itemized facts about the discovered vulnerabilities and the success or failure of the organization to remediate them

Readiness and Review Primary goal to keep information security program functioning as designed and continuously improving Accomplished by: Policy review: for policy to be sound Program review: for major planning components to be current, accurate, and appropriate Rehearsals: for major plan elements to be effective Readiness And Review The primary goal of the readiness and review domain is to keep the information security program functioning as designed and continuously improving over time. This is accomplished by: Policy review: Sound policy needs to be reviewed and refreshed from time to time to provide a current foundation for the information security program. Readiness review: Major planning components should be reviewed on a periodic basis to ensure they are current, accurate, and appropriate. Rehearsals: When possible, major plan elements should be rehearsed. Policy review is the primary initiator of the readiness and review domain. As policy is revised or current policy is confirmed, the various planning elements are reviewed for compliance, the information security program is reviewed, and rehearsals are held to make sure all participants are capable of responding as needed.

Summary Successful organizations have multiple layers of security in place: physical, personal, operations, communications, network, and information. Security should be considered a balance between protection and availability Information security must be managed similar to any major system implemented in an organization using a methodology like SecSDLC Implementation of information security often described as a combination of art and science

Information Security Principles & Applications

Similar presentations

Presentation on theme: "Information Security Principles & Applications"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Information Security Principles & Applications

Similar presentations

Presentation on theme: "Information Security Principles & Applications"— Presentation transcript:

Similar presentations

About project

Feedback