<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Carter Codell – Module 2</title>
    <link>/docs/cy5200/module2/</link>
    <description>Recent content in Module 2 on Carter Codell</description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Mon, 13 Jan 2020 22:47:54 -0500</lastBuildDate>
    
	  <atom:link href="/docs/cy5200/module2/index.xml" rel="self" type="application/rss+xml" />
    
    
      
        
      
    
    
    <item>
      <title>Docs: Project Definition</title>
      <link>/docs/cy5200/module2/chapter3/</link>
      <pubDate>Mon, 13 Jan 2020 22:48:10 -0500</pubDate>
      
      <guid>/docs/cy5200/module2/chapter3/</guid>
      <description>
        
        
        &lt;p&gt;Creating a risk assessment project requires knowledge of the budget, objective, scope, and level of rigor of analysis expected.&lt;/p&gt;
&lt;p&gt;Success cannot be achieved until the meaning of success is defined.
For a risk assessment project, success is defined as achieving customer satisfaction, quality technical work, and project completion within budget.&lt;/p&gt;
&lt;h3 id=&#34;customer&#34;&gt;Customer&lt;/h3&gt;
&lt;p&gt;The customer is primarily the project sponsor.
The secondary customers include any other stakeholders in the process, including:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;security officer or security team&lt;/li&gt;
&lt;li&gt;business unit managers&lt;/li&gt;
&lt;li&gt;compliance officer legal department&lt;/li&gt;
&lt;li&gt;risk assessment method&lt;/li&gt;
&lt;li&gt;risk assessment team&lt;/li&gt;
&lt;li&gt;objective review&lt;/li&gt;
&lt;li&gt;security professionals&lt;/li&gt;
&lt;li&gt;technicians, operators, and administrators&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;quality&#34;&gt;Quality&lt;/h3&gt;
&lt;p&gt;The quality of work is very important, since most customers will view the success of the project based on the final report.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Quality Expected in Any Report&lt;/strong&gt;:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;grammatically correct&lt;/li&gt;
&lt;li&gt;visually pleasing&lt;/li&gt;
&lt;li&gt;addresses its intended audience&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;Quality Expected in Technical Reports&lt;/strong&gt;:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;technically accurate&lt;/li&gt;
&lt;li&gt;describes approach&lt;/li&gt;
&lt;li&gt;clearly presented conclusions&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;Quality Expected in Security Risk Assessment Reports&lt;/strong&gt;:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;clear and accurate indentification of risk&lt;/li&gt;
&lt;li&gt;adequate and relevant evidence&lt;/li&gt;
&lt;li&gt;clear and relevant recommendations&lt;/li&gt;
&lt;li&gt;clear compliance results&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;budget&#34;&gt;Budget&lt;/h3&gt;
&lt;p&gt;The budget helps define the rigor of the risk assessment.
A $250,000 risk assessment will need more rigor than a $50,000 risk assessment.
Some factors include the organization size, geographic separation, complexity, and threat environment&lt;/p&gt;
&lt;h3 id=&#34;objective&#34;&gt;Objective&lt;/h3&gt;
&lt;p&gt;The objective needs to be set at the beginning of the project.
Example &amp;ndash; &amp;ldquo;accurate analysis of the effectiveness of current security control that protect an organization&#39;s assets.&lt;/p&gt;
&lt;h3 id=&#34;limiting-the-scope&#34;&gt;Limiting the Scope&lt;/h3&gt;
&lt;p&gt;The boundaries of a security risk assessment are determined by the sponsor of the security risk assessment.
Identifying the security risk assessment boundaries is essential for the security risk assessment team to ensure that neither underscoping nor overscoping occurs.&lt;/p&gt;
&lt;h3 id=&#34;security-controls-and-assets&#34;&gt;Security Controls and Assets&lt;/h3&gt;
&lt;p&gt;Group controls by Management-Operational-Technical (MOT).
Group assets by Tangible and Intangible.&lt;/p&gt;
&lt;h3 id=&#34;identifying-system-boundaries&#34;&gt;Identifying System Boundaries&lt;/h3&gt;
&lt;p&gt;There are many ways to set the boundary for a risk assessment such as physical (workstations, firewalls) or logical (don&#39;t assess functions from another assessment).&lt;/p&gt;
&lt;h3 id=&#34;specifying-the-rigor&#34;&gt;Specifying the Rigor&lt;/h3&gt;
&lt;p&gt;The rigor should be based on the maturity of the security program.
The risk assessment could last 1 week to 6 months.&lt;/p&gt;
&lt;h2 id=&#34;project-description&#34;&gt;Project Description&lt;/h2&gt;
&lt;p&gt;Set the scope, boundaries, and rigor.
Have a statement of work that specifies the work to be performed, including threats, assets, controls, and tasks of the security risk assessment.
The &amp;ldquo;service&amp;rdquo; can/should be described as&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;an objective analysis of the effectiveness of the current security controls that protect an organization&#39;s assets and a determination of the probability if losses to those assets.
Such analysis shall consist of an identification of tangible and intangible assets under protection, an identification of the threats to and vulneravility likelihood, the impact of the threat to the identified assets, and recommendations for security controls to mitigate the risks.&lt;/p&gt;
&lt;/blockquote&gt;

      </description>
    </item>
    
    <item>
      <title>Docs: Information Security Risk Assessment Basics</title>
      <link>/docs/cy5200/module2/chapter2/</link>
      <pubDate>Mon, 13 Jan 2020 22:48:00 -0500</pubDate>
      
      <guid>/docs/cy5200/module2/chapter2/</guid>
      <description>
        
        
        &lt;p&gt;The risk assessment process:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Project Definition&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;Project scope&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Budget&lt;/li&gt;
&lt;li&gt;Objective&lt;/li&gt;
&lt;li&gt;Assets&lt;/li&gt;
&lt;li&gt;Controls&lt;/li&gt;
&lt;li&gt;Boundaries&lt;/li&gt;
&lt;/ul&gt;
&lt;ol&gt;
&lt;li&gt;Project Preperation&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;Team preperation&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Select team&lt;/li&gt;
&lt;li&gt;Introduce team&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Project preperation&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Obtain permission&lt;/li&gt;
&lt;li&gt;Review business mission&lt;/li&gt;
&lt;li&gt;Identify crital applications&lt;/li&gt;
&lt;li&gt;Map assets&lt;/li&gt;
&lt;li&gt;Identify threats&lt;/li&gt;
&lt;li&gt;Determine expected controls&lt;/li&gt;
&lt;/ul&gt;
&lt;ol&gt;
&lt;li&gt;Data Gathering&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;Administration&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Policy reivew&lt;/li&gt;
&lt;li&gt;Procedure review&lt;/li&gt;
&lt;li&gt;Training review&lt;/li&gt;
&lt;li&gt;Organization review&lt;/li&gt;
&lt;li&gt;Interviews&lt;/li&gt;
&lt;li&gt;Observation&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Technical&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Design review&lt;/li&gt;
&lt;li&gt;Configuration review&lt;/li&gt;
&lt;li&gt;Architectural review&lt;/li&gt;
&lt;li&gt;Security testing&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Physical&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Policy review&lt;/li&gt;
&lt;li&gt;Procedure review&lt;/li&gt;
&lt;li&gt;Observation&lt;/li&gt;
&lt;li&gt;Inspection&lt;/li&gt;
&lt;/ul&gt;
&lt;ol&gt;
&lt;li&gt;Risk Analysis&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;Determine risk&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Asset valuation&lt;/li&gt;
&lt;li&gt;Threat and vulnerability mapping&lt;/li&gt;
&lt;li&gt;Calculate risk&lt;/li&gt;
&lt;li&gt;Create risk statements&lt;/li&gt;
&lt;li&gt;Obtain team consensus&lt;/li&gt;
&lt;/ul&gt;
&lt;ol&gt;
&lt;li&gt;Risk Mitigation&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;Safeguard selection&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Safeguard cost&lt;/li&gt;
&lt;li&gt;Safeguard effectiveness&lt;/li&gt;
&lt;li&gt;Solution sets&lt;/li&gt;
&lt;/ul&gt;
&lt;ol&gt;
&lt;li&gt;Recommendations&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;Risk recommendation&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Risk acceptance&lt;/li&gt;
&lt;li&gt;Risk mitigation&lt;/li&gt;
&lt;li&gt;Risk assignment&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;Executive summary&lt;/li&gt;
&lt;li&gt;Report&lt;/li&gt;
&lt;li&gt;Appendices&lt;/li&gt;
&lt;li&gt;Presentation&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Phase 1: Project Definition is discussed more in Chapter 3.
Phase 2: Project Preparation is discussed more in Chapter 4.
Phase 3: Data Gathering is discussed more in Chapter 5.&lt;/p&gt;
&lt;h3 id=&#34;phase-4-risk-analysis&#34;&gt;Phase 4: Risk Analysis&lt;/h3&gt;
&lt;p&gt;The risk analysis phase involves a review of the data gathered and an analysis of the resulting risk to the organization.
Several elements of the risk analysis phase are considered key concepts within security risk assessments: assets, threats, vulnerabilities, and security risk.&lt;/p&gt;
&lt;p&gt;Assets are the information and resources that have value to an organization.
Assets are to risk assessments because the enumeration of assets helps to scope the risk assessment and the valuation of assets helps to determine the countermeasures deployed.&lt;/p&gt;
&lt;p&gt;Threat agents cause threats to happen.
Threats help scope the vulnerabilities of the system being assessed.
Threat agents could be nature, employees, malicious hackers, industrial spies, foreign government spies.
Threats could be errors/omissions, fraud/theft, sabotage, loss of physical and infrastructure support, espionage, malicious code, disclosure.&lt;/p&gt;
&lt;p&gt;A vulnerability is a flaw or oversight in an existing control that may allow a threat agent to exploit it.
Vulnerabilities are important elements of a securit risk assesment because they are instrumental in determining existing and residual risk.&lt;/p&gt;
&lt;p&gt;Security risk is the loss potential to an organization&#39;s assets that will likely occur if a threat is able to exploit a vulnerability.
Security risk can be either quantitative or qualitative.
Quantitative means the risk calculation relies on specific formulas.
This means the calculation is objective and is terms of dollars, but the calculations are complex and accurate values are difficult to obtain.
Qualitativee means the risk calculation relies on subjective measuring.
This may be easy to understand, but may not be trusted by some in management.&lt;/p&gt;
&lt;h3 id=&#34;phase-5-risk-mitigation&#34;&gt;Phase 5: Risk Mitigation&lt;/h3&gt;
&lt;p&gt;The risk mitigation phase depends on safeguard selection and residual risk.&lt;/p&gt;
&lt;p&gt;A safeguard is a technique, activity, or technology employed to reduce the risk to the organization;s assets.
A safeguard may prevent, detect, or minimize the potential loss to an organization&#39;s assets.
Safeguards are classified as preventative (deter attacks from happening), detective (indicate that an attack has happened), or corrective (correct the damaage caused by an attack).&lt;/p&gt;
&lt;p&gt;Residual security risk is the risk that remains after implementation of recommended safeguards.
This risk is defined as static (the risk always exists) or dynamic (the risk may be reduced through the controls).&lt;/p&gt;
&lt;h3 id=&#34;phase-6-risk-reporting-and-resolution&#34;&gt;Phase 6: Risk Reporting and Resolution&lt;/h3&gt;
&lt;p&gt;The final report should provide clear information for executive, management, and technical personnel.&lt;/p&gt;
&lt;p&gt;Risk resolution is the decision by senior management of how to resolve the risk resented to them.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Risk reduction - the reduction of risk to an acceptable level through the adoption of additional controls of the improvement of existing controls.&lt;/li&gt;
&lt;li&gt;Risk acceptance - the deliberate decision by senior management to accept an identified risk based on business objectives&lt;/li&gt;
&lt;li&gt;Risk transference - the contractual transfer of risk to another organization through outsourcing or insurance.&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
  </channel>
</rss>
