Domain 1 – Security Management Practices Flashcards
Government Classification Terms:
• Unclassified – Neither sensitive nor classified, public release is acceptable • Sensitive But Unclassified (SBU) – Minor secret, no serious damage if disclosed • Confidential – disclosure could cause damage to National Security • Secret - disclosure could cause serious damage to National Security • Top Secret – Highest Level - disclosure could cause exponentially grave damage to National Security
Public Classification Terms
• Public – similar to unclassified, should not be disclosed but is not a problem if it is • Sensitive – data protected from loss of Confidentiality and integrity • Private – data that is personal in nature and for company use only • Confidential – very sensitive for internal use only - could seriously negatively impact the company
Classification Criteria
• Value - number one criteria, if it is valuable it should be protected • Age – value of data lowers over time, automatic de-classification • Useful Life – If the information is made obsolete it can often be de-classified
Personal Association
If the data contains personal information it should remain classified
Distribution may be required in the event of the following:
• Court Order – may be required by court order • Government Contracts – government contractors may need to disclose classified information • Senior Level Approval – senior executives may approve release
Owner
• May be executive or manager • Owner has final corporate responsibility of the data protection • Makes determination of classification level • Reviews classification level regularly for appropriateness • Delegates responsibility of data protection to the Custodian
Custodian
• Generally IT systems personnel • Running regular backups and testing recovery • Performs restoration when required • Maintains records in accordance with the classification policy
User
• Anyone the routinely uses the data • Must follow operating procedures • Must take due care to protect • Must use computing resources of the company for company purposes only
Policies Standards, Guidelines and Procedures
• Policies are the highest level of documentation • Standards, Guidelines and Procedures derived from policies • Should be created first, but are no more important than the rest
Senior Management Statement – general high-level statement
• Acknowledgment of importance of computing resources • Statement of Support for information security • Commitment to authorize lower level Standards, Guidelines and Procedures
Regulatory Policies
Company is required to implement due to legal or regulatory requirements • Usually very detailed and specific to the industry of the organization • Two main purposes • To ensure the company is following industry standard procedures • To give the company confidence they are following industry standard procedures
Advisory Polices
Not mandated but strongly suggested. • Company wants employees to consider these mandatory. • Advisory Policies can have exclusions for certain employees or job functions
Informative Policies
• Exist simply to inform the reader • No implied or specified requirements
Standards, Guidelines and Procedures
• Contain actual detail of the policy • How the policies should be implemented • Should be kept separate from one another • Different Audiences • Security Controls are different for each policy type • Updating the policy is more manageable
Standards
Specify use of technology in a uniform way, compulsory
Guidelines
similar to standards but not compulsory, more flexible
Procedures
Detailed steps, required, sometimes called “practices”, lowest level
Baselines
baselines are similar to standards, standards can be developed after the baseline is established
Roles and Responsibilities-Senior Management
Has ultimate responsibility for security
Roles and Responsibilities-Infosec Officer
Has the functional responsibility for security
Roles and Responsibilities-Owner
Determines the data classification
Roles and Responsibilities-Custodian
Preserves C.I.A.
Roles and Responsibilities-User
Performs in accordance with stated policy
Roles and Responsibilities-Auditor
Examines Security
Identification of Risk
• Actual threat • Possible consequences • Probable frequency • Likely hood of event
Risk Analysis
• Identification of risks • Benefit - cost justification of counter measures
Risk Analysis Terms
• Asset – Resource, product, data • Threat – Action with a negative impact • Vulnerability – Absence of control • Safeguard – Control or countermeasure
Exposure Factor
% of asset loss caused by threat
SLE
Single Loss Expectancy Expected financial loss for single event
ARO
Annualized Rate of Occurrence represents estimated frequency in which threat will occur within one year
ALE
Annualized Loss Expectancy Annually expected financial loss
Risk Analysis
• Risk analysis is more comprehensive than a Business Impact Analysis • Quantitative – assigns objective numerical values (dollars) • Qualitative – more intangible values (data) • Quantitative is a major project that requires a detailed process plan
PSE
Preliminary Security Examination • Often conducted prior to the quantitative analysis. • PSE helps gather elements that will be needed for actual RA
Risk Analysis Steps
1) Estimate of potential loss 2) Analyze potential threats 3) Define the Annualized Loss Expectancy (ALE)
Categories of Threats-Information
Warfare – technically oriented terrorism
Categories of Threats-Personnel
Unauthorized system access
Categories of Threats-Application / Operational
ineffective security results in data entry errors
Categories of Threats-Criminal
Physical destruction, or vandalism
Categories of Threats-Environmental
utility outage, natural disaster
Categories of Threats-Computer Infrastructure
Hardware failure, program errors
Categories of Threats-Delayed Processing
reduced productivity, delayed collections processing
Risk analysis should contain the following:
• Valuation of Critical Assets • Detailed listing of significant threats • Each threats likelihood • Loss potential by threat • Recommended remedial safeguards
Remedies
Risk Reduction - implementation of controls to alter risk position Risk Transference – get insurance, transfer cost of a loss to insurance Risk Acceptance – Accept the risk, absorb loss
Qualitative Scenario Procedure
• Scenario Oriented • List the threat and the frequency • Create exposure rating scale for each scenario • Scenario written that address each major threat • Scenario reviewed by business users for reality check • Risk Analysis team evaluates and recommends safeguards • Work through each finalized scenario • Submit findings to management
Value Assessment
• Asset valuation necessary to perform cost/benefit analysis • Necessary for insurance • Supports safeguard choices
Safeguard Selection
• Perform cost/benefit analysis • Costs of safeguards need to be considered including • Purchase, development and licensing costs • Installation costs • Disruption to production • Normal operating costs
Cost Benefit Analysis
ALE (PreControl) – ALE (PostControl) = Annualized value of the control
Level of manual operations
• The amount of manual intervention required to operate the safeguard • Should not be too difficult to operate
Auditability and Accountability
Safeguard must allow for auditability and accountability
Recovery Ability
• During and after the reset condition • No asset destruction during activation or reset • No covert channel access to or through the control during reset • No security loss after activation or reset • Defaults to a state that does not allow access until control are fully operational
Security Awareness Training
Benefits of Awareness • Measurable reduction in unauthorized access attempts • Increase effectiveness of control • Help to avoid fraud and abuse Periodic awareness sessions for new employees and refresh other
Methods of awareness improvement
• Live interactive presentations • CBTs • Publishing of posters and newsletters • Incentives and awards • Reminders, login banners
Training & Education Types Are:
• Security training for Operators • Technical training • Infosec training • Manager training
Deterrent
Intended to discourage a potential attacker : fences lightning
Security framework
Program made up of many components: logical administrative, and physical
BS799
British Standard 799 Was developed in 1995 defined how Information Security Management system should be built and maintained ant has two parts: Part1 outlines control objectives Part2 ISMS
ISO/IEC 27000
standards that attempt to compartmentalize and modularize the necessary components of an ISMS, as shown here: • ISO/IEC 27000 Overview and vocabulary • ISO/IEC 27001 ISMS requirements • ISO/IEC 27002 Code of practice for information security management • ISO/IEC 27003 Guideline for ISMS implementation • ISO/IEC 27004 Guideline for information security management measurement and metrics framework • ISO/IEC 27005 Guideline for information security risk management • ISO/IEC 27006 Guidelines for bodies providing audit and certification of information security management systems • ISO/IEC 27011 Information security management guidelines for telecommunications organizations • ISO/IEC 27031 Guideline for information and communications technology readiness for business continuity • ISO/IEC 27033-1 Guideline for network security • ISO 27799 Guideline for information security management in health organizations
PDCA
Plan- Do- Check- ACT Used in ISO/IEC 27000 series
Zachman Framework
Model for the development of enterprise architectures developed by John Zachman What,How,Where,When,Why Planner,Owner,Designer,Builder,Worker
TOGAF
Model and methodology for the development of enterprise architectures developed by The Open Group Used to develop the following architecture types: Business,Data,Applications,Technology.
DODAF
Department of Defense architecture framework Focuses on: Command control,communications,computers,intelligence,surveillance and reconnaissance systems and processes.
MODAF
British ministry of defense architecture framework Based upon DoDAF, get data in the right format,to the right people ASAP.
SABSA
Sherwood Applied Business Security Architecture Similar to Zachman Framework(Enterprise Architecture), defines business requirements from security perspective . Each layer decries in abstraction: Contextual,Conceptual,Logical,Physical,Component,Operational. • What are you trying to do at this layer? The assets to be protected by your security architecture. • Why are you doing it? The motivation for wanting to apply security, expressed in the terms of this layer. • How are you trying to do it? The functions needed to achieve security at this layer. • Who is involved? The people and organizational aspects of security at this layer. • Where are you doing it? The locations where you apply your security, relevant to this layer. • When are you doing it? The time-related aspects of security relevant to this layer.
CobiT
Control objectives for information and related technology set of control objectives for IT management developed by Information Systems Audit and Control Association (ISACA) and IT governance institute Security Controls development Plan and organize,Acquire and implement,Deliver and support, and monitor and evaluate IT products. Was derived from COSO -Controls to reduce risk of financial fraud Similar to NIST 800-53
Sp 800-53
Set of controls to protect U.S. federal systems developed by the National Institute of Standards and Technology (NIST) outlines controls that agencies need to put into place to be compliant with the Federal Information Security Management Act of 2002
COSO
Controls to reduce risk of financial fraud developed by Comittee of Sponsoring Organizations COSO 1985 Co
Six Sigma
Six Sigma is a process improvement methodology. developed by Motorola It is the “new and improved” Total Quality Management (TQM) Is used to identify defects in processes so that the processes can be improved upon.
CMMI
Capability Maturity Model Integration (CMMI) Process improvement model developed by Carnegie Mellon. CMMI is a maturity model that allows for processes to improve in an incremented and standard approach.
ADM
Architecture Development Method (ADM). This method is an iterative and cyclic process that allows requirements to be continuously reviewed and the individual architectures updated as needed. These different architectures can allow a technology architect to understand the enterprise from four different views (business, data, application, and technology) so she can ensure her team develops the necessary technology to work within the environment and all the components that make up that environment and meet business requirements.
Architecture Frameworks
Who the stakeholders? What information they need? MODAF:British ministry of defense architecture framework DODAF:Department of Defense architecture framework TOGAF:The Open Group architecture framework Zachman Framework 1980
Enterprise Security Architecture
Subset of enterprise architecture Strategy how to make up ISMS Make sure that security efforts aligned with practices in standardized cost effective manner.
Strategic alignment
Strategic alignment means the business drivers and the regulatory and legal requirements are being met by the security enterprise architecture. Security efforts must provide and support an environment that allows a company to not only survive, but thrive.
ITIL
Information Technology Infrastructure Library is the de facto standard of best practices for IT service management.
IRM
Information risk management (IRM) is the process of identifying and assessing risk reducing it to an acceptable level implementing the right mechanisms to maintain that level.
Information Risk Management Policy
Proper risk management requires a strong commitment from senior management, a documented process that supports the organization’s mission, an information risk management (IRM) policy, and a delegated IRM team. The IRM policy should address the following items: • The objectives of the IRM team • The level of risk the organization will accept and what is considered an acceptable level of risk Formal processes of risk identification • The connection between the IRM policy and the organization’s strategic planning processes • Responsibilities that fall under IRM and the roles to fulfill them • The mapping of risk to internal controls • The approach toward changing staff behaviors and resource allocation in response to risk analysis • The mapping of risks to performance targets and budgets • Key indicators to monitor the effectiveness of controls
IRM team.
The Risk Management Team The overall goal of the team is to ensure the company is protected in the most cost-effective manner. This goal can be accomplished only if the following components are in place: • An established risk acceptance level provided by senior management • Documented risk assessment processes and procedures • Procedures for identifying and mitigating risks • Appropriate resource and fund allocation from senior management • Security-awareness training for all staff members associated with information assets • The ability to establish improvement (or risk mitigation) teams in specific areas when necessary • The mapping of legal and regulation compliancy requirements to control and implement requirements • The development of metrics and performance indicators so as to measure and manage various types of risks • The ability to identify and assess new risks as the environment and company change • The integration of IRM and the organization’s change control process to ensure that changes do not introduce new vulnerabilities
SP 800-30
NIST developed a risk methodology, which is published in their SP 800-30 document. This NIST methodology is named a “Risk Management Guide for Information Technology Systems” and is considered a U.S. federal government standard. It is specific to IT threats and how they relate to information security risks. It lays out the following steps: • System characterization • Threat identification • Vulnerability identification • Control analysis • Likelihood determination • Impact analysis • Risk determination • Control recommendations • Results documentation
FRAP
Facilitated Risk Analysis Process. The crux of this qualitative methodology is to focus only on the systems that really need assessing to reduce costs and time obligations. It stresses prescreening activities so that the risk assessment steps are only carried out on the item(s) that needs it the most.
OCTAVE
Another methodology called OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) was created by Carnegie Mellon University’s Software Engineering Institute. It is a methodology that is intended to be used in situations where people manage and direct the risk evaluation for information security within their company. This places the people that work inside the organization in the power positions as being able to make the decisions regarding what is the best approach for evaluating the security of their organization. This relies on the idea that the people working in these environments best understand what is needed and what kind of risks they are facing.
FRAP vs OCTAVE
The scope of an OCTAVE assessment is usually very wide compared to the more focused approach of FRAP. Where FRAP would be used to assess a system or application, OCTAVE would be used to assess all systems, applications, and business processes within the organization.
