Methodologies Flashcards Preview

CISSP > Methodologies > Flashcards

Flashcards in Methodologies Deck (29):
1

(ISC)2 Code of Ethics

1. Protect society, the commonwealth, and the infrastructure

2. Act honorably, honestly, justly, responsibly, and legally

3. Provide diligent and competent service to principals

4. Advance and protect the profession

2

1. Protect society, the commonwealth, and the infrastructure(ISC)2 Code of Ethics

 Promote and preserve public trust and confidence in information and systems.

 Promote the understanding and acceptance of careful information security measures.

 Preserve and strengthen the integrity of the public infrastructure.

 Discourage unsafe practice

3

2. Act honorably, honestly, justly, responsibly, and legally

 Tell the truth; make all stakeholders aware of your actions on a timely basis.

 Observe all contracts and agreements, express or implied.

 Treat all constituents fairly. In resolving conflicts, consider public safety and duties to principals, individuals, and the profession in that order.

 Give prudent advice; avoid raising unnecessary alarm or giving unwarranted comfort. Take care to be truthful, objective, cautious, and within your competence.

 When resolving differing laws in different jurisdictions, give preference to the laws of the jurisdiction in which you render your service.

4

3. Provide diligent and competent service to principals

 Preserve the value of their systems, applications, and information.

 Respect their trust and the privileges that they grant you.

 Avoid conflicts of interest or the appearance thereof.

 Render only those services for which you are fully competent and qualified.

5

4. Advance and protect the profession

 Sponsor for professional advancement those best qualified. All other things equal, prefer those who are certified and who adhere to these canons. Avoid professional association with those whose practices or reputation might diminish the profession.

 Take care not to injure the reputation of other professionals through malice or indifference.

 Maintain your competence; keep your skills and knowledge current. Give generously of your time and knowledge in training others.

6

Computer Ethics Institute

1. Thou shalt not use a computer to harm other people.

2. Thou shalt not interfere with other people’s computer work.

3. Thou shalt not snoop around in other people’s computer files.

4. Thou shalt not use a computer to steal.

5. Thou shalt not use a computer to bear false witness.

6. Thou shalt not copy or use proprietary software for which you have not paid.

7. Thou shalt not use other people’s computer resources without authorization or proper compensation.

8. Thou shalt not appropriate other people’s intellectual output.

9. Thou shalt think about the social consequences of the program you are writing or the system you are designing.

10. Thou shalt always use a computer in ways that ensure consideration and respect for your fellow humans.

7

Internet Activities Board’s (IAB)

• Seeks to gain unauthorized access to the resources of the Internet;

• Disrupts the intended use of the Internet;

• Wastes resources (people, capacity, computer) through such actions;

• Destroys the integrity of computer-based information;

• Compromises the privacy of users.

8

NIST Special Publication 800-61 outlines the incident response life cycle

1) Preparation: steps taken before an incident occurs. These include training, writing incident response policies and procedures, and providing tools to handle incidents effectively.

2) Detection and analysis (identification): analyze events to is determined whether an incident is actually occurring or has occurred.

3) Containment: Keep further damage from occurring as a result of the incident but the threat still there, perform a binary (bit by bit) forensic backup, Capture volatile data,

4) Eradication (Remediation and review): remove threats, Understanding the root cause of the incident. Restore the system to a good state and should not be vulnerable to further impact. The restore involves either rebuilding the system from scratch or restoring from a known good backup

5) Recovery: It ensures that the system is validated, properly restored to operation status, and monitored for potential further compromise.

6) Lesson learned:
goal is to provide a final report on the incident, which will be delivered to management. Feedback from this phase feeds directly into continued preparation, where the lessons learned are applied to improve preparation for handling future incidents.


 

9

The six phases in incident response according to (ISC)2?

1) triage

2) notification and identification

3) action/reaction

4) containment, analysis, tracing

5) follow-up

6) repair, recovery, prevention

10

The six phases in incident response according to (ISC)2?

1. Triage phase: encompasses the detection, identification, and notification subphases.

• Determine the seriousness of the incident and to filter out false-positives.

• Classify the type of incident.

• Determine the level of potential risk or criticality of the incident.

2. Investigate phase: analysis, interpretation, reaction, and recovery from an incident.

• Reduce the impact of the incident, identify the root cause, get back up and running, and prevent the incident from occurring again.

• Chain of custody.

3. Containment: contain the incident to prevent an outbreak.

4. Analysis and Tracking: examine and analyze what has occurred, with a focus on determining the root cause.

      • Ultimate goal is to obtain sufficient information to stop the current incident, prevent future “like” incidents from occurring, and identify what or whom is responsible.

5. Recovery: deals with recovery, repair, and prevention of the affected systems and assets.

    • The goal is to get the business back up and running.

11

The six phases in incident response according to (ISC)2?

3. Containment: contain the incident to prevent an outbreak.

4. Analysis and Tracking: examine and analyze what has occurred, with a focus on determining the root cause.

• Ultimate goal is to obtain sufficient information to stop the current incident, prevent future “like” incidents from occurring, and identify what or whom is responsible.

5. Recovery: deals with recovery, repair, and prevention of the affected systems and assets.

• The goal is to get the business back up and running

12

Publication 800-30, Risk Management Guide for IT Systems - Risk Assessment methodology

1. System Characterization: describes the scope of the risk management effort and the systems that will be analyzed.

2. Threat Identification.

3. Vulnerability Identification.

4. Control Analysis: analyzes the security controls (safeguards) that are in place or planned to mitigate risk. List of controls and planned controls.

5. Likelihood Determination: likelihood rating.

6. Impact Analysis: loss of C.I.A. and impact rating.

7. Risk Determination: especially those risks with high-likelihood/high-impact/consequences.

8. Control Recommendations: These 7 steps are used to determine Control recommendations.

9. Results Documentation: the strategy is documented and RA report.

13

OCTAVE

stands for Operationally Critical Threat, Asset, and Vulnerability Evaluation, a risk management framework from Carnegie Mellon University.

o Phase 1 identifies staff knowledge, assets, and threats.

o Phase 2 identifies vulnerabilities and evaluates safeguards.

o Phase 3 conducts the Risk Analysis and develops the risk mitigation strategy.

14

Within the Common Criteria, there are seven EALs

• EAL 1 – Functionally tested - A user wants the system to operate but ignores security threats.

• EAL 2 – Structurally tested - Developers use good design practices but security is not a high priority.

• EAL 3 – Methodically tested and checked - Developers provide moderate levels of security.

• EAL 4 - Methodically designed, tested, and reviewed - Security configuration is based on good commercial development. This level is the common benchmark for commercial systems, including operating systems and products.

EAL 5 – Semi-formally designed and tested - Security is implemented starting in early design. It provides high levels of security assurance.

EAL 6 - Semi-formally verified, designed and tested - Specialized security engineering provides high levels of assurance. This level will be highly security from penetration attackers.

• EAL 7 – Formally verified, designed and tested - Extremely high levels of security are provided. This level requires extensive testing, measurement, and independent testing.

15

What are the steps in the business continuity planning process?

 Develop the continuity planning policy statement.

 Conduct the BIA.

 Identify preventative controls.

 Develop recovery strategies.

 Develop the contingency plan.

 Test the plan, and conduct training and exercises.

 Maintain the plan.

16

BIA has 4 steps:

• Gathering the needed assessment materials.

o Org charts to determine functional relationships.

o Examine business success factors.

• Performing the vulnerability assessment.

o Identify Critical IT resources out of critical processes.

o Identify disruption impacts and Maximum Tolerable Downtime (MTD).

o Loss Quantitative (revenue, expenses for repair) or qualitative (competitive edge, public embarrassment). Presented as low, high, medium.

o Develop recovery procedures: procedures should take place to restore a system and its data files after system failure.

• Analyzing the information compiled.

o Document the process.

o Identify inter-dependability.

o Determine acceptable interruption periods.

• Documenting the results and presenting recommendations to management.

17

Software Capability Maturity Model (CMM)

is a maturity framework for evaluating and improving the software development process (reduce life cycle of development), improving quality software better project management capabilities.

Initial stage

Managed stage

Defined stage

 

18

Software Capability Maturity Model (CMM) - Five Maturity Levels

Initial: the process is not very well-defined and most activities are reactive. No effective management procedures and plans. There is no assurance of consistency, and quality is unpredictable.

RepeatableBasic project management processes. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

Defined—the process is now generally proactive and universally established across the organization but it is not really measured for effectiveness.

ManagedDetailed measures of the software process and product quality are collected, analyzed, and used to control the process. Both the software process and products are quantitatively understood, measured and controlled.

Optimizing—Continual process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies

19

NIST SP 800-14  SDLC

1) Security plan

2) Project initiation phase

3) Development/Acquisition

4) Implementation

5) Operation/Maintenance

6) Disposal

20

NIST SP 800-14 phases

1) Prepare a Security Plan. to ensure that security is considered during all phases of the IT system life cycle.

2) Project initiation phase: consideration of security requirements and identify the relevant threats and vulnerabilities through risk analysis.

3) Development/Acquisition: - designed, purchased, programmed

Determine security requirements; technical features, assurance, operatonal practice.

Incorporate Security Requirements into Specifications;

Obtain the System and Related Security Activities: developing features, monitoring the development process itself for security problems, responding to changes, and monitoring threats.

4)  Implementation—Intsall system; security testing; involves certification and accreditation process

5) Operation/Maintenance:

    Security Operations and Administration—Examples include   backups, training, managing cryptographic keys, user administration, and patching.
    Operational Assurance—Examines whether a system is operated according to its current security requirements.
    Audits and Monitoring—

6) Disposal: The secure decommission of a system

21

ITIL

 

Service Strategy: addresses new business needs by describing the range of services that are or will be deployed.

Service Design: focuses on creating the services described within the service portfolio. Also focuses on management systems and architectures that guide or constrain design as well as the design processes.

Service Transition: concerned with translating designs into operational services through a standard project management structure.

Service Operation: covers IT operations controls and ensure that metrics are being captured.

Service Improvement: describes ways to improve existing IT services.

22

Change Management Control

1) Request in the form of a business case argument.
2) Impact assessment to operations.
3) Approval/Disapproval.
4) Build and Test: should be tested in nonproduction environment and documented.
5) Notification: users are notified of the proposed change and the schedule of deployment.
6) Implementation and monitoring.
7) Reporting results of the change implementation


is to ensure that the intended machines received the deployment package.















 
















Documentation: include system modifications and lessons learned.
















 

23

Configuration management

is a process of identifying and documenting hardware components, software, and the associated settings.
The change is requested.

The change is approved.

The change is documented in the change log.

The change is tested and presented.

The change is implemented.

24

Spiral Model steps

1) product design,
2) system requirements,
3) concept of operations,
4) implementation.

Each round included multiple repeated steps, including prototype development and a risk analysis. A risk analysis is performed each round to lower the overall risk of the project. The spiral ended with successful implementation of the project.

25

Disaster Recovery Process

Respond: begins the process of assessing the damage to determine if the event in question constitutes a disaster.

Activate the team responsible for recovery needs. Calling trees is needed.
Communication: out-of-band. Disseminating details regarding the organization’s recovery status to the public.

Assess: assess the extent of the damage to determine the proper steps necessary to ensure the organization’s ability to meet its mission and maximum tolerable downtime (MTD).

Reconstitution: successfully recover critical business operations either at a primary or secondary site.

26

NIST Special Publication 800-61 outlines the incident response life cycle

1. Preparation: includes steps taken before an incident occurs. These include training, writing incident response policies and procedures, and providing tools to handle incidents effectively.

2. Detection and analysis (aka identification): events are analyzed in order to determine whether an incident is actually occurring or has occurred.

3. Containment: keep further damage from occurring as a result of the incident, such as taking a system off the network, isolating traffic, powering off the system, also perform a binary (bit by bit) forensic backup.

4. Eradication: involves:
      1. Removing any malicious software from a compromised system
      2. Understanding the root cause of the incident so that the    system can be reliably cleaned and safely restored to operational status. The cause must be determined so that the systems in question can be returned to a known good state without risk of compromise persisting or reoccurring.
      3. Restore the system to a good state and should not be vulnerable to further impact. The restore involves either rebuilding the system from scratch or restoring from a known good backup.
     4. Strengthening the defenses of the system.

5. Recovery: involves cautiously restoring the system or systems to operational status. It ensures that the system is validated, properly restored to operation status, and monitored for potential further compromise. The business unit responsible for the system will dictate when the system will go back online.

6. Lessons learned. The goal is to provide a final report on the incident, which will be delivered to management. Feedback from this phase feeds directly into continued preparation, where the lessons learned are applied to improve preparation for handling future incidents.

 

27

steps in a forensic investigation

1) Identification

2) Preservation: imaging technologies, chain of custody standards, hashing, checksum

3) Collection

4) Examination: traceability, validation, filtering,..

5) Analysis

6) Presentation: documentation, expert testimony,..

7) Decision: reports, court decisions, and internal decisions.

28

Incident Handling and Response

1) Triage: encompasses the detection, identification, and notification sub-phases to determine the seriousness of the incident and to filter out false-positives. Next step is identifying or classifying the type of incident.

2) Investigative Phase: deals directly with the analysis and recovery from an incident. Reduce the impact of the incident, identify the root cause, get back up and running in the shortest possible time, and prevent the incident from occurring again.

3) Containment: contain the incident to prevent outbreak and to reduce the potential impact of the incident.

4) Analysis and Tracking: begin to examine and analyze what has occurred, and determine the root cause to determine the actual source and the point of entry into the network. The ultimate goal is to obtain sufficient information to stop the current incident, prevent future “like” incidents from occurring, and identify what or whom is responsible.

5) Recovery phase: deals with recovery, repair, and prevention of the affected systems and assets. The goal of this phase is to get the business back up and or, bring the affected systems back into production.

6) Reporting and Documenting: debriefing and feedback phase. Start collecting meaningful data that can be used to develop or track performance metrics for the response team.

29

Developing a BCP/DRP: NIST 800-34 steps

1. Develop the contingency planning policy statement—
    Develop an effective contingency plan.
    Define the organization’s overall contingency objectives – what assets needs protection.
    Obtain senior management support.

2. Conduct the business impact analysis (BIA)—
    Identify and prioritize critical IT systems and components.
    Correlate the system with the critical mission/business   processes and services provided, and based on that information, characterize the consequences of a disruption.

3. Identify preventive controls—Measures taken to reduce the effects of system disruptions can increase system availability and reduce contingency lifecycle costs. Ex: fire suppression system; offsite storage of backup media…

4. Develop recovery strategies—thorough recovery strategies ensure that the system may be recovered quickly and effectively following a disruption. Based on MTD result, the recovery strategies will be chosen.

5. Develop an IT contingency plan—the contingency plan should contain detailed guidance and procedures for restoring a damaged system. Ex: alternate site, backup methods,..

6. Plan testing, training, and exercises—testing the plan identifies planning gaps, whereas training prepares recovery personnel for plan activation; both activities improve plan effectiveness and overall agency preparedness.

7. Plan maintenance—the plan should be a living document that is updated.