Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
106 Cards in this Set
- Front
- Back
|
First principle of COBIT standard |
Meet stakeholder needs |
|
|
Second principle of COBIT standard |
Cover the enterprise end-2-end |
|
|
Third principle of COBIT |
Apply a single, integrated framework for security |
|
|
Fourth principle of COBIT |
Enable a holistic approach to security |
|
|
Fifth principle of COBIT |
Separate governance from management |
|
|
1- Highest-level security role as defined by ISC2 |
Security Owner (manager) |
|
|
2- Security role defined by ISC2 beneath "Security Owner" |
Security Professional - responsible for security, including writing policy and implementing it |
|
|
3- Security role defined by ISC2 beneath the "Security Professional" |
Data Owner - The data owner is responsible for the data being protected - Tends to defer day-to-day tasks to a data custodian |
|
|
4- Security role defined by ISC2 beneath "Data Owner" |
Data Custodian - The owner is just TOO BUSY to deal with the day to day management of data, so that's this person's job - They are responsible for implementing and maintaining the systems necessary for security (dont' forget the CIA triad!) - Work must be in line with security policies - They have day-to-day responsibility for handling classified material |
|
|
5- Security role defined by ISC2 beneath "Data Custodian" |
User - End users actually use the systems created and maintained by the data custodian - Responsible for adhering to security policies and procedures |
|
|
6- Security role defined by ISC2 beneath "User" |
Auditor - verifies that security policy is properly applied |
|
|
Major step or phase in implementation of a classification scheme (Who?) |
Identify the custodian of the data - This is people-centric - Is the owner the custodian, or someone else? |
|
|
Major step or phase in implementation of a classification scheme (How?) |
Specify criteria to classify data - How will the data be classified? - How many different levels? |
|
|
Major step or phase in implementation of a classification scheme (Work phase :/ ) |
Classify and label each resource/object - Tends to be done by an owner or custodian - Everything needs a classification - Without classification a resource can't be guaranteed protective controls |
|
|
Major step or phase in implementation of a classification scheme (Exceptions) |
Document any exceptions to classification policy - If there are things that need exceptions, define them - After defining them, make sure the documentation finds its way into the review process! |
|
|
Major step or phase in implementation of a classification scheme (Protection) |
Select security controls for each classification - Management controls? - Technical controls? |
|
|
Major step or phase in implementation of a classification scheme (How do we "undo" this?) |
Declassification procedures - How can resources be declassified? - What procedures are followed? - How do we prepare a resource or object for transfer to an external entity? |
|
|
Major step or phase in implementation of a classification scheme (education) |
Awareness program - Without awareness, security will fail - Instruct how the classification scheme is setup - Ensure people know their role and what to do |
|
|
4 Elements of a complete organizational security policy |
- Standards - Baselines - Guidelines - Procedures |
|
|
Standards |
One of the 4 components of a complete organizational secuirty policy: Standards are compulsory requirements (not optional) They provide a way for technology and procedures to be uniformly implemented Like: - Engineering security standards - Other things like that |
|
|
Baselines |
One of the 4 components of a complete organizational secuirty policy: - Defines the minimum security for each system - Establishes a foundational secure state that additional security measures can build on - Usually system specific or based on industry standards |
|
|
Guidelines |
One of the 4 components of a complete organizational secuirty policy: - Offers recommendations on how to apply standards and baselines - Serve as an operational guide for security professionals and users - Describes the desired state of security to be achieved rather than prescribing specific products or control configurations |
|
|
Procedures |
One of the 4 components of a complete organizational secuirty policy: - Detailed step-by-step document - Ensure consistent application of policies, standards and guidelines (repeatability!) - System and software specific - Require regular updates as systems and software change |
|
|
Reduction analysis |
Key part of threat modeling. Next step after detailing out specific technologies, patch levels and protocols (etc...) are in your system: - Divide the system into smaller and smaller pieces (subroutines, methods, operating systems, physical systems / software or departments, tasks, networks, blah) - Identify 5 concepts in the system: 1- Trust boundaries 2- Data Flow paths 3- Input points 4- Privileged operations 5- Details on security stance and approach (i.e. what security assumptions are made, how is the unit secure?) |
|
|
Strategic Plan |
Long term plan that is pretty stable over time. Represents Vision. Keeps security in alignment with organizational goals, missions and objectives. Typically updated annually, looks out about 5 years |
|
|
Tactical Plan |
Mid-term plan with more details on accomplishing goals in the strategic plan. This type of plan can be crafted on an ad-hoc basis to handle unexpected events. Typically useful for abouta year, this typ eof plan often prescribes and schedules tasks necessary to accomplish goals examples: maintenance plans, support plans, hiring plans |
|
|
Operational Plan |
Short-term plan, highly detailed. Must be updated regularly to stay relevant. Includes resource allotments, budget and staff. Examples include: system deployment plans, training plans, product design plans |
|
|
Government/Military Data Classification: Highest level |
Top Secret
- Unauthorized disclosure of top secret information will have drastic effects and cause grave danger to national security |
|
|
Government/Military Data Classification: Pretty high level data, but not the highest! |
Secret
- Restricted data - Disclosure will have significant effects and cause critical damage to national security |
|
|
Government/Military Data Classification: Lowest 'classified' level |
Confidential
- Used for private, sensitive, proprietary or valuable information - Disclosure will have noticeable effects and cause serious harm to national security |
|
|
Government/Military Data Classification: Screwball level |
Sensitive (but unclassified) - Not well explained - Maybe used to categorize data that is mildly impacting on a national security level(??) |
|
|
Government/Military Data Classification: Lowest level |
Unclassified - Data is neither sensitive nor classified - Disclosure of data does not compromise confidentiality - No harm to national security |
|
|
Commercial / private classification scheme: Highest level |
Confidential
- Extremely sensitive information - Meant for internal use only - Can encompass 'proprietary' information if that does not have its own classification scheme This could have competitive consequences or other drastic effects on the company if disclosed |
|
|
Commercial / private classification scheme: Not my data, but still important |
Private - Data of a private or personal nature - Intended only for internal use - Can describe company data does not own yet needs to maintain for customers Significant negative impact can occur to the business or named individuals if private data is disclosed |
|
|
Commercial / private classification scheme: Squishy level |
Sensitive - More sensitive than 'public' information - Not specifically proprietary or dangerous to the company - There could be negative impact if sensitive data is disclosed |
|
|
Commercial / private classification scheme: Lowest level |
Public - Used for data that does not fit a higher level classification - No serious risk of negative impact for the organization |
|
|
Due Care |
Using reasonable care to protect interests of an organization. Examples include developing a formalized security structure in the company and including policies, standards, baselines, guidelines and procedures |
|
|
Due Diligence |
Practicing activities that promote due care. Needs to be demonstrable over time to be effective. |
|
|
Operational Security |
Ongoing maintenance of continued care and due diligence by all responsible parties in an organization. I see it as all parties working together to ensure that the day-to-day operations of the company are not compromised and remain secure. |
|
|
What does CBK stand for?
|
Common Body of Knowledge
(8 domains) |
|
|
Describe a secure personnel onboarding process |
- Create a Job description - Set the security classification for the position/role - Screen candidates for the position (Screening effort should be proportional to the amount of harm someone could cause the organization) - Hire a suitable candidate that meets the security as well as operational criteria - Ensure training is sufficient to describe the role's operational and security procedures |
|
|
Separation of Duties |
Critical or sensitive tasks are divided among administrators or high-level users. This attempts to minimize the effects of deliberate or accidental efforts to subvert the security system. This can reduce the impact of 2 or more people colluding to violate security policy. |
|
|
Job Responsibilities (from a security POV) |
Users should only be granted the minimum access they need to perform their required work. This only works to the extent that you can grant low-level, granular access to resources and functions. Companies in the real world may not meet all textbook requirements to be 100% compliant. |
|
|
Job Rotation |
According to the book: - Knowledge redundancy: reduce downtime or outages because multiple employees can step in to get things working again. - Reduced riskf of fraud, theft or misuse: If an employee attempts to misuse or abuse a role that OTHER employees who know the roles duties will be able to spot the problem quickly. - The book calls it 'peer auditing' / collusion prevention I am skeptical to the practical security benefits of this. The knowledge redundancy makes a lot of sense to me though! |
|
|
Collusion |
Several people working together to perpetuate a crime is known as 'collusion' To reduce risk of collusion: - Restrict job responsibilities - Have clearly defined job roles - Employ separation of duties - Try job rotation Strict monitoring of special privileges (admin, backup operator, etc...) can help detect collusion. |
|
|
Job Descriptions |
- Clarify the role that the organization needs - Help determine security privileges and controls that should be used - *SHOULD* be updated regularly for new roles as well as current employees to ensure they don't drift out of the appropriate security controls |
|
|
Employee Candidate Screening |
The book suggests (depending on the role to be filled): - Background checks - Criminal / legal history - Identification verification - Neighbor / aquaintance conversations - Social media / public posts - Personality testing - Personal interview |
|
|
Employment agreements and policies |
Employees should sign documents that signify understanding of: - policies - procedures - job responsibilities - Disciplinary rules - employment length/duration (as appropriate) NDAs can be used to protect confidential/sensitive data from leaking after employees leave Non-competes can be useful when applied correctly. Unfortunately the book advocates using them in a threatening way. |
|
|
Employment agreements and policies ::::: Regular Managerial Maintenance |
Like technology systems, people systems should be regularly reviewed. Consider an employee and their role throughout their 'employment lifetime': - Have their duties and privileges drifted? - Is their specific work documented? Changes in role without pruning privileges can result in security violations. |
|
|
Employment termination
|
- Must have robust policies in place
- Have to demonstrate that policies are consistently and uniformly applied over time - Take proper precautions to ensure that your interests are looked after during the termination and off-boarding process Personal note: Don't dehumanize people you let go. You've accounted for their humanity in security policy, standards and procedures- don't get lazy at the end! |
|
|
SLAs |
Popular way to apply controls to: - Contractors - Consultants - Vendors Specify things like: - Expectations - Performance requirements - Compensation - Consequences for violation |
|
|
Compliance: Personnel |
Compliance in general means to comply with all pertinent regulations/standards/etc... that your business is required to adhere to. Employees need proper training if they are to be expected to follow all policies and procedures and maintain compliance. |
|
|
Privacy: Personnel |
There are several/many definitions of and opinions about privacy. For your organization, be sure have a CLEARLY DEFINED privacy policy that spells out what employees, customers, suppliers, contractors and others can expect. The policy must/should address laws, regulations, standards and agreements that your company is subject to. What data do we collect? how do we handle it? How do we store it? How do we use it? When will it be destroyed (if ever)? |
|
|
Security Governance: Risk Management |
Security governance concerns itself with practices that support, define and direct the security efforts of an organization. (ties into corporate and IT governance in many places) 3rd party governance is oversight: - By a governing body to your organization - By you to 3rd parties you outsource or perform work for you (they must comply with your restrictions, standards and regulations for *you* to be compliant) |
|
|
Security governance: Risk Management: Auditing and Assessment |
Auditing and Assessments occur between a governing body and a target. They should be open and transparent so real issues get identified and expectations stay realistic. |
|
|
Security governance: Risk Management: Auditing and Assessment: Documentation Review |
A Documentation Review is a key part of this and helps ensure that stated organizational goals are reflected in actual operation. It can help identify areas of waste where you can make changes to be more cost effective. The review should support security by identifying and reducing vulnerabilities as well as covering 'avoidance', 'reduction' or 'mitigation' of risk. |
|
|
Define Risk |
The possibility that something could happen to DAMAGE, DESTROY or DISCLOSE data. |
|
|
How do Security Professionals employ Risk Management? |
Security aims to PREVENT loss or disclosure of data while SUSTAINING authorized access. In order to effectively carry this out, security professionals need to understand risk management The whole purpose of security is to prevent risks from becomingrealized by removing vulnerabilities and blocking threatagents from jeopardizing assets. Risk Management helps guide security efforts, impacts security governance and helps set legal precedence that demonstrates Due Dare and Due Dilligence |
|
|
Risk Management Principles |
- Identify factors that could damage or disclose data - Evaluate the factors in light of the VALUE of the data and the COST of countermeasures - Implement COST EFFECTIVE solutions to mitigate or reduce risk Goal is to reduce risk to a level that is acceptable to the organization and its mission |
|
|
Risks around IT Infrastructure |
- Logical / technical attacks (spyware, malware, virus, spoofing, phishing, improper permissions etc...) - Physical (network tap, destroying hardware, stealing hardware, interrupting essential utilities) Computers and equipment still exist in the real world- consider the physical threats! |
|
|
Risk Analysis |
Process used to achieve the goals of risk management. This ongoing effort includes: - Examining an environment for risks - Evaluating threats based on LIKELIHOOD of attack and COST OF DAMAGE - Evaluate the cost of countermeasures for potential threats ** In order for any of this to work, proper ASSET VALUATIONS must be assigned. Spending $1000 to secure $10 of equipment is dumb. |
|
|
Risk Terminology: Asset |
Anything that should be protected. It can be anything used in a business process or work task. Not limited to hardware, it can be stuff like: Programs, software, products, databases, furniture, personnel, facilities, recipes / formulas / specifications If your organization places ANY VALUE on an item it controls and DEEMS IT IMPORTANT ENOUGH TO PROTECT it should be considered an asset |
|
|
Risk Terminology: Asset Valuation |
The DOLLAR FIGURE assigned to an asset based on COST and EXPENSES Expenses can include: development, maintenance, administration, support, repair costs. As well as less tangible items like: public confidence, industry support or productivity enhancement |
|
|
Risk Terminology: Threats |
Any event or occurence that causes undesirable or unwanted outcomes.
These can be caused by ACTION or INACTION and could cause damage, destruction, alteration, loss or disclosure of assets |
|
|
Risk Terminology: Vulnerability |
Weakness in an asset, safeguard or countermeasure. Perhaps the ABSENSE of a safeguard or countermeasure. Vulnerabilities are flaws, loopholes, oversights, errors, limitations, fragility of a system or process Loss or damage result when vulnerabilities get exploited |
|
|
Risk Terminology: Exposure |
Being SUSCEPTIBLE to asset loss. There is a POSSIBILITY that a vulnerability can or will be exploited
This does not mean that a realized threat has or is actually occurring |
|
|
Risk Terminology: Experienced Exposure |
Exposure to a REALIZED THREAT. Threats are realized when a threat actor exploits a vulnerability. |
|
|
Risk Terminology: Risk |
Possibility or likelihood that a threat will exploit a vulnerability to cause harm to an asset risk = threat * vulnerability Reducing threats or vulnerabilities decreases risk |
|
|
Risk Terminology: Safeguards (countermeasures) |
Security involves itself with the implementation of SAFEGUARDS A Safeguard or countermeasure removes, eliminates or reduces vulnerabilities or protects against specific threats. Examples include: software patches, improving security policy, improving personnel training, installing fences, etc... |
|
|
Risk Terminology: Attack |
Act of exploiting a vulnerability. Intentional attempt to exploit vulnerabilities to cause damage, loss or disclosure.
Pedantics note: any violation or failure to adhere to organizational security policy. |
|
|
Risk Terminology: Breach |
Breaches occur when security mechanisms are bypassed or thwarted by a threat agent. When combined with an Attack, penetration or intrusion can result. Penetration means that a threat agent has gained access to your organization |
|
|
Risk Relationships |
- Threats exploit vulnerabilities, which results in exposure. (Exposure is increased because if SOMEONE, SOMEWHERE has a vulnerability that is exploited it means that you have exposure if you share that vulnerability) - Exposure is risk - Risk is mitigated by safeguards - Safeguards protect assets that are in danger by threats |
|
|
Risk Relationships: Elements of risk: Image |
|
|
|
Risk Management: Threat Identification
|
Best handled by a CROSS-FUNCTIONAL team comprised of representatives from each DEPARTMENT at the company.
Can / should be a mix of security professionals as well as domain experts. |
|
|
Elements of Quantitative Risk Analysis |
- Assign Asset Value (AV) - Calculate the Exposure Factor (EF) - Calculate the Single Loss Expectency (SLE) - Determine the Annualized Rate of Occurrance (ARO) - Derive the Annualized Loss Expectency (ALE) - Perform cost/benefit analysis of countermeasures |
|
|
Quantitative Analysis: Asset Value (AV) |
Take inventory of assets and assign a $$ figure |
|
|
Quantitative Analysis: Exposure Factor (EF) |
Create a detailed list of threats and vulnerabilities. Determine how exposed the asset is to each threat. This is represented as a percentage and represents the fraction of value that is lost in the event of a compromise for a single asset. Typically this value is not 100% since an asset can typically be salvaged after a compromise. Also known as the 'loss potential' |
|
|
Quantitative Analysis: Single Loss Expectancy (SLE) |
The (max?) cost associated with a single realized risk against a specific asset. Calculated like this: SLE = Asset Value * Exposure Factor SLE is expressed in dollars. For example: |
|
|
Quantitative Analysis: Annualized Rate of Occurrence (ARO) |
The Annualized Rate of Occurrence is how often you expect an asset to be compromised (threat or risk realized) within a single year. Figuring this out can be complicated and involve historical records, statistical analysis or guesswork.
This is a PROBABILITY calculation and for some threats or risks can be calculated by multiplying the LIKELIHOOD of an occurrence by the NUMBER OF USERS who could initiate the threat. ARO of email virus could be 10 million where the ARO of an earthquake may be 0.00001 |
|
|
Quantitative Analysis: Annualized Loss Expectancy (ALE) |
Possible yearly cost of all compromises for a single asset for the entire year. It is calculated like this: ALE = SLE * ARO Ex: Single loss of $40k, occurs 0.5 times/year ALE = $40k * 0.5 ALE = $20k |
|
|
Quantitative Analysis: ALE with a Safeguard |
When a safeguard or countermeasure is in place, you must calculate the ALE with the safeguard as well as without (how else would you determine if it is worth it to protect something?) Safeguards are primarily designed to reduce ARO, though they sometimes reduce EF, too. |
|
|
Quantitative Analysis: Annual Cost of Safeguard (ACS) |
This represents the overall cost in a given year to operate a safeguard. It should include: - Purchase, development, licensing - Implementation and customization - Annual operation, maintenance, admin costs - Annual repair and upgrade costs - Costs to or improvements in productivity - Cost to change environment to suit the safeguard - Costs around testing and evaluating the safeguard |
|
|
Quantitative Analysis: Calculate the Safeguard cost/benefit amount |
To do this you must know: - Pre countermeasure ALE - Post-countermasures ALE - The ACS of the safeguard in question Maths: |
|
|
OSI 7 layers and examples |
|
|
|
Qualitative Analysis |
System of analysis that does not rely on fixed dollar amounts to represent asset value, risk/threat costs or safeguards. More like a scale: low/medium/high -or- 1 to 10 for ranking. Qualitative analysis improves as the diversity of the people involved increases (people from management, security, business units, process experts, etc...) |
|
|
Delphi technique |
Anonymous feedback / response system that lets a group of people arrive at a consensus without indicating who advocated for what opinion or position. Cards are submitted anonymously and gathered/reviewed. The process continues until a consensus is reached |
|
|
Risk Assignment or Acceptance options |
- Reduce, Mitigate or Avoid: Employ safeguards or remove something risky (like TELNET or FTP) - Assign or transfer the risk: Insurance or outsourcing are examples of cases where a 3rd party assumes risk - Accept the risk: It is not cost effective to employ safeguards, so the business accepts the possible loss and risk. - Reject/Ignore: pretend it doesn't exist! (bad) |
|
|
Residual Risk |
Any risk that is left over after reduction, mitigation, avoidance, assignment or countermeasures are employed. This is the risk that upper management has chosen to accept. In most cases residual risk indicates that available safeguards are not cost effective. |
|
|
Total Risk |
Amount of risk an organization would have if it did not employ any safeguards or countermeasures total risk = threats +* vulnerabilities +* asset value |
|
|
Controls Gap |
Difference between the TOTAL risk and the RESIDUAL risk. This describes the amount of risk that is reduced by implementing safeguards |
|
|
Defense in depth: Implementation layers |
An asset should be protected by multiple layers of controls: - Physical (fence, door locks, guards) - Logical / technical (encryption, firewall, IDS) - Administrative/management: policies, hiring practices, business processes |
|
|
Control Types: Deterrent |
Designed to DISCOURAGE violation of security policies. Tends to rely on people CHOOSING to not take an action: |
|
|
Control Types: Preventive |
Deployed to STOP unwanted or unauthorized activity
mantraps, guards, security cameras, alarm systems, job rotation, separation of duties, data classification, security training / policies, firewalls, IDS/IPS |
|
|
Control Types: Detective |
Discovers what has happened after the fact. Show an audit trail of what happened:
security guards, CCTV, job rotation, honeypots, IDS, supervisor reviews |
|
|
Control Types: Compensating |
Give options to other existing security controls that aren't quite doing everything we need.
If PII needs protection (for example) and data is encrypted before entering the DB but *NOT* over the wire, a compensating control can help |
|
|
Control Types: Corrective |
Designed to return a system to a NORMAL state after an attack. antivirus, backup / recovery systems, take a memory dump, kill offending process and restart the system |
|
|
Control Types: Recovery |
Like a CORRECTIVE control yet has more specific, complex or advanced capabilities:
system imaging, server clustering, fault tolerant drives, VM or DB shadowing |
|
|
Control Types: Directive |
Meant to direct or control action of subjects in a system to force a certain reaction: escape route signs, public notifications, detailed procedures, supervisors/supervision, good security policy |
|
|
Continuous improvement |
Without a path to continuous improvement your security will be 'static' and subject to attack by new and evolving threats. Risk analysis and risk management are 'point in time' activities and should be performed regularly. |
|
|
NIST Risk Management Framework (RMF): Step 1 |
Categorize An information system must be categorized and understood. What type of data is stored? What is its classification? How does data get in and out of the system? Who operates it? Understand the risks associated with the system |
|
|
NIST Risk Management Framework (RMF): Step 2 |
Select baseline security controls Security controls should be an appropriate minimum for the system. This would make a baseline that is suitable for customization for other similar information systems |
|
|
NIST Risk Management Framework (RMF): Step 3 |
Implement the security controls Be sure to implement in accordance with recommendations and best practices. Correct installation is essential to proper operation |
|
|
NIST Risk Management Framework (RMF): Step 4 |
Assess the controls Are the controls working correctly? Are the results in line with expectations or desired operational characteristics? |
|
|
NIST Risk Management Framework (RMF): Step 5 |
Authorize the Information System for Use Once security controls have been applied and assessed, you can determine if the information system is fit for use. If it is you can authorize it from a security standpoint. |
|
|
NIST Risk Management Framework (RMF): Step 6 |
Continuous monitoring Even though a system is installed, assessed and authorized for use, it doesn't mean it is perfect or will function correctly forever. Be sure to continuously check the state of controls on a schedule that makes sense. Ensure changes get reviewed and documented |
|
|
|
|
