1678784047-mid_sem-2.pdf

Information Security Risk
Assessment and Assurance
CS 541 (3-1-0)
VIVEK KUMAR ANAND,
Assistant Professor,
(NIIT UNIVERSITY)

Text Books
➢William Stallings, Computer Security: Principles and Practice, Pearson
Education, 2/E, 2013
• Chapters 4,14,15
➢Matt Bishop, Introduction to Computer Security, Addison-Wesley
Professional, 1/E, 2004.

Trust and Information Security
➢ Information security does not create trust.
➢ Information security only helps in transferring trust from
where it is present to where it is necessary.

Information Security
The U.S. National Information Systems Security Glossary
defines "Information Security" as the protection of
information and information systems from unauthorized
access, use, disclosure, disruption, modification, or
destruction in order to provide confidentiality, integrity, and
availability.

Confidentiality
➢Definition: ability to hide information from those people
unauthorized to view it.
➢Need: Cryptography and Encryption.
➢Cryptography: study of secret communication
➢Encryption: ensures only the authorized person can see it.

Integrity
➢Definition: ensure that data is an accurate and unchanged
representation of the original secure information.
➢Security Attacks:
oMan in the Middle attacks.

Availability
➢Definition: ensure that the information concerned is readily
accessible to the authorized user at all times.
➢Security Attacks:
oDoS and DDos attacks.

Key challenges
How Secure is Secure Enough?
How Much Security Is Enough?

Cost Benefit Analysis
➢Optimum level of security?
➢Security Vs Convenience?
➢What security components to invest on?
➢How secure is secure enough?
➢How much should you spend on security?

Pillars of Enterprise Security
Enterprise
Security
ISACA,
NIST,
COBIT,
ITIL
Digital
Forensics
Security
Engineering
Prepares Guidelines,
Establishes standards
catch violators,
Introspection
brings guidelines
into action

Information Assurance & Security (IAS)
Octave
➢Adds 5 more things to CIA:
oPrivacy, in addition to Confidentiality
oAuthenticity, in addition to Integrity
oTrustworthiness→Availability (not an addition)
onon-repudiation,
oAccountability,
oAuditability.
Legal and cyber
forensics

Management: Security Triad
Ease of Use Cost of Operations
Business

Information Security in an
Organization
➢People: are the ones who use the IT systems and so enterprise
security has to be designed around them.
➢Process: security policies, security risk assessment and
management, monitoring.
➢Technology: what tools to use to achieve desired security targets.

Implementing Information Security
Information
Security
Policies
Procedures
and
Guidelines
Technical
Systems
Security
Awareness
Workshops
An aware workforce is the best defence
against information security threats
Suitable policies and processes need to be
implemented for effective InfoSec
The right technology needs to be
implemented for cost effective
InfoSec
People
Process
Technology

Threat
➢An event that poses some harm to the IT systems.
➢Types of Threats
oDoS.
oBreach of Confidential Information.
oData theft or alteration.
oUnauthorized use of Compute resources.
oIdentify theft.

Cyber Threat
➢Is any identified effort directed toward
oaccess to,
oexfiltration of,
omanipulation of, or
oimpairment to the
• integrity, confidentiality, security, or availability of data, an application, or
a federal system,
without lawful authority

Vulnerability
➢A deficiency on a system or resources whose exploitation leads
to the materialization of the threats.
➢Classification.
oDesign.
oImplementation.
oConfiguration.
➢Common Source Problems.
oExploitation of Out-of-Date software.
oExploitation of software default settings.

Attack
➢The actual exploitation of a vulnerability to make threat reality.
➢Some common attacks.
oDoS
oDDoS
oUnauthorized access.
oEavesdropping.
oViruses & Worms.
oInternet infrastructure attack.
oTrust Exploitation.
oSession Hijacking.
oBuffer overflow attacks

Attack Vectors
➢An “Attack Vector” is the industry’s term for describing the
path that a hacker or a malware application might follow to
compromise your data.
➢Examples:
• Compromised Credentials
• Weak and Stolen Credentials
• Malicious Insider
• Missing or Poor Encryption
• Mis-configuration
• Ransomware
• Phishing

Attack Surfaces
➢Attack surface is represented by total sum of vulnerabilities on your
IT system where an adversary can attempt to gain entry to your
information systems.
➢Attack surface is the sum of all possible security risk exposures
➢The surface is what is being attacked; the vector is the means by
which an intruder gains access.
➢Attack surfaces can be physical or digital.
➢Physical attack surfaces: desktop systems, laptops, mobile devices,
USB ports and improperly discarded hard drives.
➢Digital attack surfaces: Bugs in software

Threat Actors
➢Physical
➢Network
➢Systems
➢Software
➢Data
➢Staffing
➢Vendor
A threat actor or malicious actor is a person or entity responsible
for an event or incident that impacts, or has the potential to
impact, the safety or security of another entity.
➢Cyber Terrorists
➢Organized Crime/Cybercriminals
➢Hacktivists
➢Insiders
➢Script Kiddies
➢Internal User Errors

Risk evaluation Methodology based
on ISO27005

How do we do ensure security?
➢Security frameworks,
➢Security Policy,
➢Security standards,
➢Security controls

ISO Security Standards
➢ISO/IEC 27000: Information security management systems (ISMS) — Overview and
vocabulary.
➢ISO/IEC 27001:2013: Information technology - Security Techniques - Information
security management systems — Requirements
➢ISO/IEC 27002: Code of practice for information security controls - essentially a
detailed catalog of information security controls that might be managed through the
ISMS.
➢ISO/IEC 27003: Information security management system implementation guidance.
➢ISO/IEC 27004: Information security management — Monitoring, measurement,
analysis and evaluation
➢ISO/IEC 27005: Information security risk management.
➢ISO/IEC 27013:2015: focuses exclusively on the integrated implementation of an
information security management system (ISMS) as specified in ISO/IEC 27001

ISO/IEC 27001
➢ISO 27001 is the International standard that provides guidelines for
safeguarding an organization’s asset.
➢A framework for building a risk based security management system.
➢Focus is on establishing an Information security Management system
(ISMS) for the organization.
• Comprehensive set of Clauses and Controls comprising best practices in
information security.
• Focus on people, process and technology.
➢Considers CIA Triad

Overview
of
ISO
27001:2013
https://www.praxiom.com/iso-
27001.htm

Information Security Management
System (ISMS)
➢ISO27001: a framework of policies, procedures, guidelines
and associated resources and activities jointly managed by an
organization to protect its information assets.
➢Controls that an organization needs to implement to ensure
that it is sensibly protecting the confidentiality, availability,
and integrity of assets from threats and vulnerabilities.
➢includes information risk management.
• the assessment of the risks.
• management and protection of assets.

Relevant Standards for ISMS
➢Information Technology Infrastructure Library: ITIL certification
• for Individuals and has 5 levels.
➢COBIT framework (from ISACA).
➢The Open Group information security management maturity model.
(O-ISM3)

Implementing ISMS
(ISO 27001/GDPR)
https://ins2outs.com/implement-information-security-management-system/

Benefits from the Information Security
Management System
➢The company has defined and implemented a management system by
training employees, building awareness, applying the right security measures
and executing a systematic approach to information security management.
➢The risk related to information loss or unauthorised access is minimised.
➢Development of the awareness and competencies of people assigned to
information security roles.
➢Increased trust of customers by demonstrating that the company is ISO/IEC
27001 certified.
➢The organisation meets regulatory requirements, including those specified in
• the Personal Data Protection Regulation (EU) 2016/679,
• and the new cyber-security directive (EU) 2016/1148.

Implementing ISMS
1. Secure executive support and set the objectives.
• Budget and resource allocation.
2. Define the scope of the system.
• What aspects should your ISMS cover or focus on?
• If you can’t afford to spend time on defining scope, simply adopt guidelines as given
in ISO27001.
3. Evaluate assets and analyse the risk.
• Identify assets: anything that deals with information processing (or holding).
• For EU countries it translates to Personal Data Protection Regulation (EU) 2016/679
(more popularly called as GDPR).
• classification of assets and associated risk analysis is to be done.
• Identify a person/role for each asset.
• a risk management plan is specified

Implementing ISMS
4. Define the Information Security Management System
• Policies
• Processes
• Procedures
• Instructions
• Inputs/Outputs
• Training
• Guides
• Sources of knowledge
• Roles
• Normative sources

Implementing ISMS
5. Train and build competencies for the Roles.
• Employee – role representing any person employed at the organisation,
• Internal auditor – role responsible for conducting management system audits,
• IT administrator – role representing people responsible for managing the IT
infrastructure of the organisation,
• Top management – role representing the group responsible for setting directions
and controlling the organisation at the top level,
• Data Protection Officer: The Personal Data Protection Regulation (EU) 2016/679
indicates the need to select a DPO, as in Data Protection Officer. DPO is responsible
for the protection of personal data in your organization.
➢System maintenance and monitoring
• Maintain records and logs necessary.
• Records and logs are vital at the time of security audit.

Implementing ISMS
6. Certification audit
• The certification audit has two phases.
o Phase I usually involves a check of the scope and completeness of the ISMS
o phase II the system is verified in terms of whether it has been implemented in the company and
actually corresponds to its operations.
o On issue of certification, periodic audits are done to ensure maintenance and improvement
o a full re-certification involving a certification audit is required every three years.
➢Maintenance and continuous improvement
• People involved in various roles are to submit improvement and change proposals.
• Conduct internal audits to identify scope for improvement.
• Provide periodic updates to top management.

Information Asset Classification
(https://policy.usq.edu.au/documents/13931PL)
➢What is an asset?
• An asset is any tangible or intangible thing or characteristic that has value to an
organization
• Examples – Customer forms, bills, Contracts, databases, IT hardware, application
software, system software, development tools, system documentation, audit
trails, etc.
➢Who is owner of the asset?
• Any person who has fiduciary responsibilities for the asset.
➢Why to classify Assets?
• To protect and secure as per their criticality and sensitivity.
• Helps meet regulatory and legal requirements.
• Helps meet requirements of industry standards.

Information Classification
➢Information Classification
• Information classification is the organization of information assets
according to their sensitivity to disclosure.
• Information must be handled in accordance with its classification.
➢Classification Systems
• Classification systems are labels that we assign to identify the
sensitivity levels.
• Labels must be clear & self-explanatory
• In electronic form, the label should be made part of the file name
• In printed form, the label should be clearly visible on the outside
and in the header and/or footer

Information Asset Classification Baseline
➢Public: Non-Sensitive Information Available for external release.
• Examples include periodicals, bulletins, financial statements, press releases, etc.
➢Internal: Information that is generally available to employees and approved non-
employees such as contractors, trainees.
• Examples include Staff memos, news letters, staff awareness program documentation or bulletins, etc.
➢Confidential: Information that is less sensitive & related to business, is intended for use by
employees, its other business units, approved non-employees such as contractors,
trainees and customer and can be printed in hard copy format.
• Examples include departmental memos, work programs, schedules, plans, etc.
➢Highly Confidential: Information that is sensitive & related to project & personnel, is
intended for use by employees, customer and approved non-employees such as
contractors, trainees can be printed in hard copy format only with the approval of HODs.
• Examples include personal information, business plans, unpublished financial statements, etc.
➢Secret: Information that is highly sensitive within and outside organization, Shall be
applied to the documented information Leakage of which can cause damage to National
Security.
• Examples include Design documents , drawings, contracts etc.

Information Asset Classification ..contd.
➢Government & Military Classification Systems
• Top Secret: applied to “any information or material the unauthorized
disclosure of which reasonably could be expected to cause an
exceptionally grave damage to the national security”
• Secret: applied to “any information or material the unauthorized
disclosure of which reasonably could be expected to cause serious
damage to the national security”
• Confidential: applied to “any information or material the unauthorized
disclosure of which reasonably could be expected to cause damage to
the national security”
• Unclassified: applied to “any information that can generally be
distributed to the public without any threat to national interest”.

Information Asset Classification ..contd
➢Commercial classification systems:
• No standard: each company can choose its own system that matches its culture
and needs
• Usually less complex than the government system
• The more regulated a company, the more complex the classification system they
adopt.
➢Most systems revolve around these four classification levels.
• Confidential:
• Sensitive
• Restricted
• Public

Information Classification Program
Lifecycle
➢Assess value of information in the asset that needs to be protected.
➢Identify the information owner.
➢Assign a information label to the asset.
➢Design controls based on the information label.
➢Perform cost benefit analysis associated with the cost of protecting assets.
➢Maintain an accurate record of asset inventory.
➢Policy of information Reclassification and Declassification.

Value and Criticality of Information
➢Calculating the value of an asset:
• Cost to acquire or develop asset
• Cost to maintain & protect asset
• Cost to replace asset
• Importance of asset to owner
• Competitive advantage of the information
• Marketability of information
• Impact on deliver of services
• Reputation
• Liability issues
• Regulatory compliance requirements

Plan-Do-Check-Act
(PDCA)
https://creately.com/blog/diagrams/deming-pdca-cycle/

PDCA Approach for ISMS
➢A regular information security team meeting is scheduled at fixed intervals (e.g.
monthly or quarterly).
➢The information security team meeting should have an agenda based on PDCA.
➢You should also apply continuous improvement to the way the information security
team works.
➢The ‘check’ part is often facilitated by including feedback collection in every
activity.
➢When discussing new controls to implement, the security team should understand
that measuring effectiveness is necessary in order to improve.
➢It is important that you are not running too many experiments. The idea behind
PDCA is that you do experiments one after another.

Health Insurance Portability and
Accountability Act (HIPAA)
➢assure that individuals’ health information is properly protected
while allowing the flow of health information needed to provide and
promote high quality health care and to protect the public's health
and well being.
➢The Privacy Rule standards address the use and disclosure of
individuals’ health information—called “protected health
information” by organizations subject to the Privacy Rule — called
“covered entities,” as well as standards for individuals' privacy rights
to understand and control how their health information is used.
https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html
https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act

Entities of HIPAA
➢Health Plans.
➢Health Care Providers.
➢Health Care Clearinghouses.
➢Business Associates
https://www.vairix.com/tech-blog/hipaa-for-software-developers

What Information is Protected?
➢ "individually identifiable health information" held or transmitted by
a covered entity or its business associate, in any form or media,
whether electronic, paper, or oral.
➢“Individually identifiable health information”
• the individual’s past, present or future physical or mental health or condition,
• the provision of health care to the individual, or
• the past, present, or future payment for the provision of health care to the
individual,

Payment Card Industry Data Security
Standard (PCI DSS)
➢Due to the increase in credit card fraud and scams each institution started
implementing their own security measures.[1990-2000]
➢Multiple standards evolved for card security.
• Visa's Cardholder Information Security Program
• MasterCard's Site Data Protection
• American Express's Data Security Operating Policy
• Discover's Information Security and Compliance
• the JCB's Data Security Program
➢Multiple standards lead to interoperability issue.
➢So PCI DSS brought common security standards to allow interoperability.

https://www.cardknox.com/white-papers/payments-industry-landscape/

PCI DSS: Validation of Compliance
➢Qualified Security Assessor (QSA)
➢Internal Security Assessor (ISA)
➢Report on Compliance (ROC)
➢Self-Assessment Questionnaire (SAQ)
https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard

Standard (PCI DSS)
➢Build and Maintain a Secure Network and Systems.
1. Install and maintain a firewall configuration to protect cardholder data.
2. Do not use vendor-supplied defaults for system passwords and other security
parameters.
➢Protect Cardholder Data.
3. Protect stored cardholder data.
4. Encrypt transmission of cardholder data across open, public networks.
➢Maintain a Vulnerability Management Program.
5. Protect all systems against malware and regularly update anti-virus software or
programs.
6. Develop and maintain secure systems and applications
https://www.cryptomathic.com/news-events/blog/topic/pci-dss#:~:text=A.%20M.%20Parker%20(guest)-
,An%20Introduction%20to%20PCI%20DSS,numerous%20additional%20security%20threats%20%26%20vulnerabilities.

Standard (PCI DSS)
➢Implement Strong Access Control Measures.
7. Restrict access to cardholder data by business need to know.
8. Identify and authenticate access to system components.
9. Restrict physical access to cardholder data.
➢Regularly Monitor and Test Networks.
10. Track and monitor all access to network resources and cardholder data.
11. Regularly test security systems and processes.
➢Maintain an Information Security Policy.
12. Maintain a policy that addresses information security for all personnel.

Standard (PCI DSS)
➢Each requirement and sub-requirement are further defined
into 3 parts.
• Requirement Statement/Description: It actually describes the
requirement. PCI DSS compliance is validated against these
requirements.
• Testing Procedures: It defines the methods to be followed by the
evaluator to validate that the requirement has been implemented.
• Guidance: It illustrates the main fundamental objective of the
requirement. It may also contain the helping material in contribution
to the proper thoughtfulness of the requirement.
Quiz: What is the latest authentication change in card based payments?

Secure Electronic Transaction (SET)
Protocol
➢It has to provide mutual authentication i.e., customer (or cardholder)
authentication by confirming if the customer is intended user or not
and merchant authentication.
➢Confidentiality: It has to keep the PI (Payment Information) and OI
(Order Information) confidential by appropriate encryptions.
➢Integrity: It has to be resistive against message modifications i.e., no
changes should be allowed in the content being transmitted.
➢SET also needs to provide interoperability and make use of best
security mechanisms.
https://www.geeksforgeeks.org/secure-electronic-transaction-set-protocol/
https://cisomag.eccouncil.org/deconstructing-apple-card-a-hackers-perspective/
https://www.freecodecamp.org/news/how-apple-pay-works-under-the-hood-8c3978238324/

PCI DSS Compliance Levels
➢Level 1 – Over 6 million transactions annually
➢Level 2 – Between 1 and 6 million transactions annually
➢Level 3 – Between 20,000 and 1 million transactions annually
➢Level 4 – Less than 20,000 transactions annually

GDPR Regulation
➢is a set of rules about how companies should process the
personal data of data subjects.
➢lays out responsibilities for organizations to ensure the privacy
and protection of personal data.
➢provides data subjects with certain rights.
➢assigns powers to regulators to ask for demonstrations of
accountability or even.
➢impose fines in cases where an organisation is not complying
with GDPR requirements.

GDPR Principles
➢Lawful, fair and transparent processing.
➢Limitation of purpose, data and storage.
➢Data subject rights
➢Consent
➢Personal data breaches
➢Privacy by Design
➢Data Protection Impact Assessment
➢Data transfers
➢Data Protection Officer.
➢Awareness and training

Data subject rights according to GDPR
➢Right to information
➢Right to access
➢Right to rectification
➢Right to withdraw consent
➢Right to object
➢Right to object to automated processing
➢Right to be forgotten
➢Right for data portability

Who does it apply to?
➢All organisations that process personal data and operate within, or
sell goods to the EU are impacted by the GDPR.
➢Processing: cover practically every type of data usage and includes
collection, storage, retrieval, alteration, storage and destruction.
➢The GDPR applies to both data ‘controllers’ and ‘processors’.
➢Data controllers determine the purpose and manner in which data
is processed.
➢Data processors are any third-party undertaking data processing
on behalf of a controller.

What is personal data?
➢Article 4 of the GDPR defines personal data as ‘any information
relating to an identified or identifiable natural person’.
➢definition of personal data to include all information that could
be used to indirectly identify individuals.
• ID numbers
• IP addresses and cookie IDs
• HR records
• Customer contact details
• Health records
• Biometrics
• CVs and employment details
• CCTV and call recordings

Same law throughout Europe
➢The GDPR applies in all EU Member states, which makes it
easier for both businesses and citizens.
➢Organisations that violate the law may face sanctions of up
to the higher amount of 4% of their global sales (the last 12
months) or € 20 million.

Data Usage and Processing
➢Processing must have a defined purpose.
➢Cannot collect data for future needs.
➢Transparency about how the data is being utilized.
➢Organisations must only store personal data as long as it is
necessary.
➢processing must be safe and secure.
➢maintain the proper documentation that shows that they comply
with the regulations.

Legal basis for use of personal data
➢GDPR sets out six alternatives to the legal basis
• Consent
• performance of a contract
• a legitimate interest
• a vital interest
• a legal requirement
• a public interest

Transparency
➢Provides each person with certain rights of their personal
data.
➢People have the right to gain access to their personal data.
➢People have a right to know how an organization is using the
data, to object to the processing, etc.

Responsibilities of data controller
➢All obligation are borne by the data controller even if the
mistake is made by supplier.
➢Data controller to contractually regulate that its suppliers follow
the data protection obligations.
➢Personal data breaches must be reported within 72 hours to the
appropriate authority.
➢In case of health or financial data each affected individual is to
be informed within 72 hours.

Sarbane-Oxley (SOX) Act
➢Bring transparency in financial reporting and corporate
governance in public companies with the intention to protect
investors and the public against corporate financial fraud and
mismanagement.
➢Penalties for Noncompliance
• Delisting of stock from public stock exchanges
• Fines of up to five million dollars
• Up to 20 years in prison (for CEOs and CFOs who willfully submit an incorrect
certification audit)
• Invalidation of D&O insurance policies.
• Clawback of any bonuses paid within a year of any malfeasance

IT Audit (Section 302)
➢Access Controls: Physical access of servers, password controls,
lockout screens, implementation of principle of least privilege
(POLP)
➢IT Security: Actions to prevent breaches
➢Change Management: How you use change management logs to
include and track new infrastructure, devices, and users.
➢Backup Procedures: Backup databases and store copies of
important documents and content offsite or on the cloud.
➢Data Tampering and Timeline Tracking.

The SOX Audit Process
➢Defining the Scope Using a Risk Assessment Approach
➢Determining Materiality and Risks - Accounts, Statements,
Locations, Processes, and Major Transactions
➢Identifying SOX Controls - Non-Key & Key, ITGCs, and other
Entity-Level Controls
➢Performing a Fraud Risk Assessment
➢Managing Process and Control Documentation
➢Testing Key Controls
➢Assessing Deficiencies
➢Delivering Management’s Report on Controls
https://www.auditboard.com/blog/sox-compliance/

SysAdmin, Audit, Network, and
Security (SANS) Controls
➢Inventory of Hardware Devices
➢Inventory of Software
➢Secure Configurations for Computer Systems
➢Vulnerability Assessment and Remediation
➢Malware Defenses
➢Application-Layer Software Security
➢Wireless Device Control
➢Data Recovery Capability
➢Skills Assessment and Training
➢Secure Configurations for Network Devices
https://www.sans.org/blog/sans-20-critical-security-controls-for-windows/

SysAdmin, Audit, Network, and
Security (SANS) Controls
➢Control of Network Ports, Protocols and Services
➢Administrative Privileges
➢Boundary Defense
➢Audit Logs
➢Controlled Access Based on Need To Know
➢Account Monitoring and Control
➢Data Loss Prevention
➢Incident Response
➢Secure Network Engineering
➢Penetration Tests

NIST 800-53: SECURITY AND PRIVACY
CONTROLS FOR INFORMATION SYSTEMS
AND ORGANIZATIONS
Pages 34 to 36

Must Read
➢Introduction to Computer Security by Matt Bishop.
• Chapter 2: Access control Matrix
• Chapter 4: Security Policies
• Chapter 5: Confidentiality Policies
• Chapter 6: Integrity Policies
• Chapter 7: Hybrid Policies
• Chapter 14: Access Control Mechanisms
• Chapter 18: Evaluating Systems

Access Control Systems
➢Access controls are security features that control how users and
systems communicate and interact with other systems and resources.
➢Access is the flow of information between a subject and a resource.
➢A subject is an active entity that requests access to a resource or the
data within a resource. E.g.: user, program, process etc.
➢A resource is an entity that contains the information. E.g.: Computer,
Database, File, program, Printer etc.
➢Access controls give organization the ability to control, restrict,
monitor, and protect resource confidentiality, integrity and availability.

Access Control Principles
➢Principle of Least Privilege: States that if nothing has been
specifically configured for an individual or the groups, he/she
belongs to, the user should not be able to access that resource i.e.
Default no access
➢Separation of Duties: Separating any conflicting areas of
responsibility so as to reduce opportunities for unauthorized or
unintentional modification or misuse of organizational assets
and/or information.
➢Need to know: It is based on the concept that individuals should
be given access only to the information that they absolutely
require in order to perform their job duties

Access Control Attributes
➢Subject attributes:
• age, clearance, department, role, job title.
➢Action attributes:
• action being attempted e.g. read, delete, view, approve
➢Object attributes:
• e.g. the object type (medical record, bank account etc)
➢Contextual (environment) attributes.
• attributes that deal with time, location or dynamic aspects of the access control
scenario

Access Control Criteria
➢Roles
➢Groups
➢Location
➢Time
➢Transaction Type

Access Control Models
➢Attribute/Policy-based Access Control (ABAC)
➢Discretionary Access Control (DAC): Eg: Unix
• Also called identity-based access control (IBAC).
➢History-Based Access Control (HBAC)
➢Non-Discretionary or Mandatory Access Control (MAC)
• Associated with MLS systems, SE Linux
➢Role-Based Access Control (RBAC)
• HIPAA, Gramm-Leach-Bliley, GDPR
➢Responsibility Based Access control

Access Control Techniques
➢Rule-Based Access Control (RuBAC)
• Firewall Settings
➢Constrained User Interface
➢Access Control Matrix
➢Access Control List
➢Content Dependent Access Control
• E-mail filtering, DataBase Views
➢Context Dependent Access Control

Rule-Based Access Control (RuBAC)
➢Rule-based access control uses specific rules that indicate what
can and cannot happen between a subject and an object.
➢A subject should meet a set of predefined rules before it can
access an object.
➢It is not necessarily an identity based i.e. it can be applicable to all
the users or subjects irrespective of their identities.
➢E.g.: Routers and firewall use rules to filter incoming and outgoing
packets

Constrained User Interface
➢Constrained user interfaces restrict user’s access ability by not
allowing them to request certain functions or information, or to
have access to specific system resources.
➢There are three major types of restricted interfaces:
• Menus and Shells: Users are only given the options of the commands
they can execute.
• Database Views: Are mechanisms used for restricting user access to
data that is contained in databases.
• Physically Constrained Interfaces: Can be implemented by only
providing certain keys on a keypad or touch buttons on a screen.

Content Dependent Access Control
➢Access to the objects is based on the content within the
object.
➢Example: Database Views, E-mail filtering etc.

Access Control Matrix
➢An access control matrix is a table of subjects and objects
indicating what actions individual subjects can take upon individual
objects.
➢The access rights that are assigned to individual subjects are called
capabilities and those assigned to objects are called Access Control
Lists (ACL).
➢This technique uses a capability table to specify the capabilities of
a subject pertaining to specific objects. A capability can be in the
form of a token, ticket, or key.
• Each row is a capability and each column is an ACL for a given user.
• Kerberos uses a capability based system where every user is given a ticket,
which is his capability table.

Modelling: Access Control Matrix

Access matrix with
domain Switching

Access Control Lists (ACL)
➢ACL’s are list of subjects that are authorized to access a
specific object and they define what level of authorization is
granted (both at individual and at group level)
➢ACL’s map values from the access control matrix to the
object.
➢Note: A capability table is bound to a subject, whereas an
ACL is bound to an object.

Context Dependent Access Control
➢The access decisions are based on the context of a collection
of information rather than on the sensitivity of the data.
➢Example: A firewall makes a context-based access decisions
when they collect state information on a packet before
allowing it into the network.

MLS: Multi-Level Security Systems
➢Bell-LaPadula Model
➢Biba Integrity Model

Goals of Confidentiality Policies
➢prevents the unauthorized disclosure of information.
➢Unauthorized alteration of information is secondary.
➢Emphasis is on confidentiality rather than integrity.
➢Control information flow with in an organization.

Bell-LaPadula Model
➢The Simple Security Property: No read up
➢The *-Property (Star Property): No write
down
➢The Discretionary Security Property.
➢Based on tranquillity principle.

Bell-LaPadula Model
➢Discretionary access policy ensures information flow based on
“Need to know” basis.
➢In addition uses mandatory access controls.

Simple Security Property
➢S can read O if and only if lo ≤ ls and S has discretionary read
access to O.
➢ls be the security clearance of subject S.
➢lo be the security classification of object O.
➢Ensures No read up.

*-Property (Star Property)
➢S can write O if and only if ls ≤ lo and S has discretionary
write access to O.
➢ls be the security clearance of subject S.
➢lo be the security classification of object O.
➢Ensures No write down. Prevents downgrading of the
classification label associated with the information.

Lattice Model: Need to Know
➢Add a set of categories to each security classification.
➢No subject should be able to read objects unless reading them is
necessary for that subject to perform its functions.
➢The sets of categories to which a person may have access is
simply the power set of the set of categories.

Simple Security Condition (no read up)
➢S can read O if and only if S dom O and S has discretionary read
access to O.
➢S dom O: The security level (S, C) dominates the security level (O´,
C´) if and only if S´ ≤ O and C´ ⊆ C. [C→category]
➢George is cleared into security level (SECRET, { NUC, EUR} ), DocA is
classified as ( CONFIDENTIAL, { NUC } ), DocB is classified as (
SECRET,{ EUR, US}), and DocC is classified as (SECRET, { EUR }).
• George dom DocA as CONFIDENTIAL ≤ SECRET and { NUC } ⊆ { NUC, EUR }
• George ￢ dom DocB
• George dom DocC

➢S can write to O if and only if O dom S and S has discretionary
write access to O.
➢Paul is cleared into security level (SECRET, { EUR, US, NUC })
and has discretionary read access to DocB. Paul can read DocB.
➢Because DocA dom Paul is false (because C(Paul) ⊄ C(DocA)),
Paul cannot write to DocA.
➢Quiz: How can a colonel communicate with a major?

Integrity Policies
➢An inventory control system may function correctly if the
data it manages is released; but it cannot function correctly
if the data can be randomly changed.
➢Focus is on commercial environments than military
environment.
➢Remember SOX IT controls?

Operating Environment
➢Users will not write their own programs, but will use existing
production programs and databases.
➢Programmers will develop and test programs on a nonproduction
system; if they need access to actual data, they will be given
production data via a special process, but will use it on their
development system.
➢A special process must be followed to install a program from the
development system onto the production system.
➢The special process in requirement 3 must be controlled and audited.
➢The managers and auditors must have access to both the system state and
the system logs that are generated.

Operating Principles
➢Separation of duty.
➢Separation of function.
➢Auditing.

Biba Integrity Model
➢Is opposite of Bell-LaPadula model.
➢The Simple Integrity Property: No read down
➢The *-property (Star Property): No write up
➢Microsoft implemented support for the Biba model in Windows
with their Mandatory Integrity Control.
• Critical files: System
• Regular users and objects: Medium
• Elevated users: High
• Internet Explorer: Low

Integrity levels
1. Untrusted
2. Slightly trusted
3. Trusted
4. Highly trusted
5. Unimpeachable
5>4>3>2>1

Integrity Categories
➢An example of two categories are category X = {Detroit, Chicago, New
York} and category Y = {Detroit, Chicago}.
➢X ≥ Y (X dominates Y), because Y is a subset of X.

Access Modes
➢Modify: the modify right allows a subject to write to an object.
This mode is similar to the write mode in other models.
➢Observe: the observe right allows a subject to read an object.
This command is synonyms with the read command of most
other models.
➢Invoke: the invoke right allows a subject to communicate with
another subject.
➢Execute: the execute right allows a subject to execute an
object. The command essentially allows a subject to execute a
program which is the object.

The Simple Integrity Property
➢No Read Down: s ∈ S can read o ∈ O if and only if i(s) ≤ i(o).
Read
Read
Read
Subject Object

➢No write up: s ∈ S can write to o ∈ O if and only if i(o) ≤ i(s).
Write
Write
Write
Subject Object

Invocation Property
➢ A process from below cannot request higher access;
➢A process can only invoke subjects at an equal or lower level.
➢s₁∈ S can invoke s₂∈ S if and only if i(s₂) ≤ i(s₁).

Clark-Wilson Integrity Model
➢Constrained data items (CDIs): data subject to integrity controls.
➢Integrity verification procedures (IVPs): procedures that ensure
that CDIs conform to the integrity constraints at the time the IVPs
are run.
➢Transformation Procedures (TPs): Change the state of the data
in the system from one valid state to another valid state.
➢Valid state: D + YB – W = TB
• D→ money deposited in a day
• W →money withdrawn in a day
• YB→ the amount of money in all accounts at the end of yesterday.
• TB→ the amount of money in all accounts so far today

Clark-Wilson Integrity Model
➢Certification Rules (CRs): certify that IVPs are executed
properly and TPs are do not destroy the validity of CDIs.
➢Enforcement Rules (ERs): Ensure TPs are operating only on
CDIs for which they been certified.
➢Clark-Wilson Vs Biba:
• Biba assumes all subjects are inherently trusted.
• Biba does not provide any mechanism or procedure to verify the
trusted entities their actions. Lacks separation of duties.

Multi-level and Multi Lateral security
➢In addition to the classification tiers (Multi Level Security) each
security level can also be divided into compartments (Multi
Lateral Security).
➢Classification tiers are called security clearance levels.
➢Information compartments are called security labels.
➢A Lattice Model is used to represent the hierarchy of access
permissions.

Chinese Wall Model
(Chapter 7 in Matt Bishop Book)
➢Model of a security policy that refers equally to confidentiality
and integrity.
➢Describes policies that involve a conflict of interest in business.
➢Extensively used in financial industry.
➢Implements separation of duty to avoid fraud.

Chinese Wall Model
➢Definitions
• Objects: The objects of the database are items of information
related to a company.
• company dataset: contains objects related to a single
company.
• conflict of interest: class contains the datasets of companies in
competition. Ex: {Coca-Cola, Pepsi}
• Company groups: files that belong to a company

CW-Simple Security Condition
➢S can read O if and only if any of the following holds.
• There is an object O´ such that S has accessed O´ and CD(O´) = CD(O).
• For all objects O´, O´ ∈ PR(S) ⇒ COI(O´) ≠ COI(O).
• O is a sanitized object.
➢Where,
• PR(S)→set of objects that S has read. Initially, PR(S) = ∅
• CD(O)→ the Company Dataset (CD) that contains object O.
• COI(O)→Conflict Of Interest (COI) class that contains object O.
▪ A subject s can be granted access to an object o only if the object is
in the same company group as objects already accessed by s or o
belongs to a different conflict class.

CW-*-Property
➢A subject S may write to an object O if and only if both of the
following conditions hold.
• The CW-simple security condition permits S to read O.
• For all unsanitized objects O´, S can read O´ ⇒ CD(O´) = CD(O).
▪Write access is allowed only if access is permitted by the simple
security property and no object can be read which is in a
different company dataset than the one for which write access is
requested and contains unsanitized information

Bell-LaPadula Vs Chinese Wall Models
➢Subjects in the Chinese Wall model have no associated security
labels.
➢Bell-LaPadula Model has no notion of “past accesses”.
➢Chinese wall model can be emulated using Bell-LaPadula.
• Use two security levels: Sanitized (S) and Unsanitized (U)

Bell-LaPadula Vs Chinese Wall Models
➢Chinese wall model can faithfully emulate Bell-LaPadula but
vice versa is not true.
➢This is because Bell-LaPadula does not retain the history of a
subject’s access and cannot capture changes over time.

Clark-Wilson and Chinese Wall Models
➢Chinese Wall model cannot emulate the Clark-Wilson model
fully.
➢Clark-Wilson model focusses on Verification and Validation
aspects in additional to access controls.
➢Chinese Wall model exclusively focusses on access controls.

Clinical Information Systems Security Policy
➢Medical records require policies that combine confidentiality
and integrity.
➢Conflict of interest is not a critical problem.
➢Authentication of the personnel making entries.
➢Assurance that the records have not been changed erroneously.
“A security policy model for clinical information systems”, Ross Anderson in the Proceedings of the 1996 IEEE
conference on Security and privacy

Anderson’s Model
➢Patient: is the subject of medical records, or an agent for that
person who can give consent for the person to be treated.
➢Personal health information is information about a patient’s
health or treatment enabling that patient to be identified. Also
called “medical records”.
➢A clinician is a health-care professional who has access to
personal health information while performing his or her job.
➢Does not address protection of health information of parent’s
etc.
“A security policy model for clinical information systems”, Ross Anderson in the Proceedings of the 1996 IEEE
conference on Security and privacy

Access Principles
➢Only clinicians and the patient have access to the patient’s
medical record.
➢Responsible clinician must have the right to add other clinicians
to the access control list.
➢Erroneous information should be corrected, not deleted, to
facilitate auditing of the records.
➢ Auditing also requires that all accesses be recorded, along with
the date and time of each access and the name of each person
accessing the record.

Access Principles
➢The name of the clinician, the date, and the time of the access of a
medical record must be recorded.
➢Patient’s to be informed about the list of all people who have accessed
his/her record along with date and time.
➢Patient should have the right to consent and allowed to withdraw
consent.
➢Clinical information cannot be deleted from a medical record until the
appropriate time has passed.
➢Information from one medical record may be appended to a different
medical record if and only if the access control list of the second record is
a subset of the access control list of the first.

Originator Controlled Access Control
(ORCON)
➢Disseminating rights are with the creator of the document.
➢In practice, the organization rests the control on who can access
the information rather than the employee who created the
document.
➢The object o cannot be released to subjects acting on behalf of
other organizations without X’s permission.
➢Any copies of o must have the same restrictions placed on it.
➢ORCON is a decentralized system of access control in which
each originator determines who needs access to the data.

ORCON Access Controls
➢The owner of an object cannot change the access controls of
the object. (From MAC)
➢When an object is copied, the access control restrictions of
that source are copied and bound to the target of the copy.
(From MAC)
➢The creator (originator) can alter the access control
restrictions on a per subject and per-object basis. (From
DAC)

Role-Based Access Control
➢Access to the data is not tied to any particular individual.
➢A role ‘r’ is a collection of job functions.
➢The active role of a subject s, written actr(s), is the role that s
is currently performing.
➢The authorized roles of a subject s, written authr(s), is the set
of roles that s is authorized to assume.
➢The predicate canexec(s, t) is true if and only if the subject s
can execute the transaction t at the current time.

Role-Based Access Control
➢Let S be the set of subjects and T the set of transactions. The rule of
role assignment is (∀s ∈ S)(∀t ∈ T)[ canexec(s, t) → actr(s) ≠ ∅ ].
➢Let S be the set of subjects. Then the rule of role authorization is (∀s
∈ S)[ actr(s) ⊆ authr(s) ].
➢Let S be the set of subjects and T the set of transactions. The rule of
transaction authorization is (∀s ∈ S)(∀t ∈ T)[ canexec(s, t) → t ∈
trans(actr(s)) ].
➢Hierarchical Roles: If role ri contains role rj, we write ri > rj. (∀s ∈ S)[ ri
∈ authr(s) ∧ ri > rj → rj ∈ authr(s) ]
• Separation of Duty: (∀r1, r2 ∈ R) [ r2 ∈ meauth(r1) → [ (∀s ∈ S) [ r1 ∈
authr(s) → r2 ∉ authr(s) ] ] ]

Access Control Mechanisms
(Chap14 in the book by Matt Bishop)

Quick Recap of what we learned so far
➢Frame works and standards (non-judicial)
• Guide us while framing ISMS policy and document for the organization.
➢Regulations and Acts (Judicial)
• Protect rights of citizens in cyber world just as in physical world.
➢Access Control Models. (ACM)
• Needed to ensure that only certain people have access to IT system.
➢Information Security models (ISM)
• Ensure implementation of cyber security regulations and acts.
➢Tools and Techniques.
• Provide support for implementing and monitoring ACM and ISM

Access Control Lists (ACL) and
Capability Lists
➢ACL’s are list of subjects that are authorized to access a
specific object and they define what level of authorization is
granted (both at individual and at group level)
➢ACL’s map values from the access control matrix to the
object.
➢A capability list is bound to a subject, whereas an ACL is
bound to an object.

Access Control Matrix: Example
➢S → set of subjects
➢R →set of rights, of a system.
➢An access control list (ACL) l is a set of pairs l = { (s, r) : s ∈ S, r ⊆ R }.
➢A capability list c is a set of pairs c = { (o, r) : o ∈ O, r ⊆ R }.

Access Control Lists (ACL) and
Capability List (C-List)
➢acl → function that determines the access control list l associated
with a particular object o. acl(o) = { (si, ri) : 1 ≤ i ≤ n } is that subject si
may access o using any right in ri.
• Example: acl(file 1) = { (process 1, { read, write, own }), (process 2, { append }) }
➢The interpretation of the capability list cap(s) = { (oi, ri) : 1 ≤ i ≤ n } is
that subject s may access oi using any right in ri.
• Example: cap(process 1) = { (file 1, { read, write, own }), (file 2, { read }), (process 1,
{read, write, execute, own}), (process 2, { write }) }
➢ACL: Given an object, what subjects can access it, and how?
➢C-List: Given a subject, what objects can it access, and how?

Design Questions
➢Which subjects can modify an object’s ACL?
➢If there is a privileged user (such as root in the UNIX system or
administrator in Windows NT), do the ACLs apply to that user?
➢Does the ACL support groups or wildcards (that is, can users be grouped
into sets based on a system notion of “group” or on pattern matching)?
➢How are contradictory access control permissions handled? If one entry
grants read privileges only and another grants write privileges only, which
right does the subject have over the object?
➢If a default setting is allowed, do the ACL permissions modify it, or is the
default used only when the subject is not explicitly mentioned in the ACL?

Implementation of Capabilities
➢Three mechanisms are used to protect capabilities: tags, protected
memory, and cryptography.
➢tagged architecture has a set of bits associated with each
hardware word. The tag has two states: set and unset.
➢Only a privileged process can set or unset the bits.
➢use the protection bits associated with paging or segmentation. All
capabilities are stored in a page (segment) that the process can
read but not alter.
➢Each capability has a cryptographic checksum associated with it,
and the checksum is digitally enciphered using a cryptosystem
whose key is known to the operating system.

Logical and Physical addressing

Other Aspects of Capability
Management
➢Copying and Amplifying Capabilities.
➢Revocation of Rights

Locks and Keys
➢Locks are associated with objects.
➢Keys are associated with subjects.
➢Subjects with matching keys can access objects locked with
matching locks.
➢object o is then represented as o´.
• o´ = ( E1(o), …, En(o))
➢Locks and Keys mechanism provides for a dynamic way of managing
access.

Type Checking
➢Type checking restricts access on the basis of the types of
the subject and object.
➢Type could refer to type of file as in directory or file.
➢Type could be type of segment i.e. CS, DS and SS etc.
• Is popular way to defend against buffer overflow attacks.

Ring-Based Access Control
➢Classify Data Items into different protection rings.
• Data Items are segments and could be procedure or data.
• Procedures belong to code segment.
• Data belong to data segment.
➢Different systems employ different no.of segments.
oMultics employs 64 rings [0,63].
▪ The kernel resides in ring 0.
▪ higher the ring number, the lower the privileges of the segments in that ring.
➢Each data segment is associated with a pair of ring numbers called an
access bracket (a1, a2), with a1 ≤ a2.
➢Each procedure segments is associated with a pair of ring numbers called
an call bracket (c1, c2), with c1 ≤ c2 in addition to access bracket.
➢Procedures can cross ring boundaries by raising traps and through gates.

Access Rules
➢A procedure executing in ring r wants to access a data segment.
• r ≤ a1: access permitted
• a1 < r ≤ a2: r and e access permitted; w and a access denied
• a2 < r: all accesses denied
➢A procedure executing in ring r wants to access a procedure
segment having call bracket [c1=a2,c2=a3] and with access bracket
[a1,a2]. So a1≤a2≤a3
• r < a1: access permitted, but a ring-crossing fault occurs
• a1 ≤ r ≤ a2: all accesses permitted and no fault occurs
• a2 < r ≤ a3: access permitted if made through a valid gate
• a3 < r: all accesses denied
r→read access; w→write access; e→execute; a→append

Propagated Access Control Lists
(PACL)
➢Is ideally suited for implementing ORCON.
➢Provides the creator of an object with control over who can access
the object.
➢PACLsubject subject is the originator of the PACL.
➢Only originator can modify PACL.
➢PACL(entity) is the PACL associated with entity.
➢The PACL follows the information as it flows around the system, but
an ACL stays with each object.

Establishing Trust
➢Formal Evaluation
➢Trusted Computer System Evaluation Criteria (TCSEC) (1983–1999)
➢Federal Information Processing Standards (FIPS).
➢The Common Criteria (since 1998)
➢System Security Engineering Capability Maturity Model (SSE-
CMM)

Security Standards
➢FIPS 140-2 is a cryptographic module validation (CMV) program.
➢The Certified Secure Software Lifecycle Professional (CSSLP) for
service providers.
➢Global Information Assurance Certification (GIAC) secure
software programmer.
➢Common Criteria (CC) for Information Technology Security
Evaluation (ISO/IEC 15408)

Trusted Computer System Evaluation
Criteria (TCSEC)
➢The TCSEC defines 6 evaluation classes identified by the rating scale
from lowest to highest: D, C1, C2, B1, B2, B3, and A1.
➢Each evaluation class contains both functional and assurance
requirements.
➢Heavily influenced by Bell-LaPadula Model and emphasizes
confidentiality.
➢Evaluate commercial IT products for use by US govt and military.
➢Focus in on Operating system.

TCSEC: Functional Requirements
➢Product needs to implement MAC and DAC access controls.
➢Object Reuse: information leakage through secondary memory.
➢Labels: Both subjects and objects have labels.
➢Identification and Authentication (I&A)
➢Trusted Path: provides a communication path that is guaranteed
to be between the user and the TCB.
➢Audit: addresses the existence of an audit mechanism as well as
protection of the audit data.

TCSEC: Assurance Requirements
➢Configuration Management
• begins at B2 and increases for higher levels.
• This requirement addresses the identification of configuration items, consistent
mappings among all documentation and code, and tools for generating the TCB.
➢Trusted Distribution
• addresses the integrity of the mapping between masters and on-site versions of
the software as well as acceptance procedures for the customer. This is unique
to level A1.
➢System Architecture
• mandates modularity, minimization of complexity, and other techniques for
keeping the TCB as small and simple as possible. At level B3 the TCB must be a
full reference validation mechanism

TCSEC: Assurance Requirements
➢Testing
• addresses conformance with claims, resistance to penetration and
correction of flaws followed by retesting. A requirement to search for
covert channels includes the use of formal methods at higher
evaluation levels.
➢Product Documentation
• is divided into a Security Features User’s Guide and an administrator
guide called a Trusted Facility Manual. Internal documentation includes
design and test documentation.

TCSEC: Evaluation Classes
➢D. Minimal Protection
• No security characteristics
• Evaluated at higher level and failed
➢C1. Discretionary Protection
• DAC
• Require identification & authentication
• Assurance minimal
➢C2. Controlled Access Protection
• Auditing capable of tracking each individuals access or attempt to each
object
• Most OSs at end of the TCSEC incorporated C2 requirements

➢B1. Labeled Security Protection
• MAC for specific sets of objects
• Each controlled object must be labeled for a security level & that labeling is
used to control access.
• Informal security model for both hierarchical levels and non-hierarchical
categories
• informal security model shown consistent with its axioms
➢B2. Structured Protection
• MAC for all objects
• Labeling expanded
• Trusted path for login
• Requires use of principle of least privilege
• Covert channel analysis
• Configuration management
• Formal model of security policy proven consistent with its axioms

➢B3. Security Domains
• High-level design – simple
oLayering
oAbstraction
oInformation hiding
• Tamperproof security functions
• Increased trusted path requirements
• Significant assurance requirements
• Administrator’s guide
• Design Documentation
• DTLS – Descriptive Top Level Specification

➢A1. Verified Protection
• Assurance
• Formal Methods
oCovert channel analysis
oDesign specification & verification
• Trusted distribution Increased test and design documentation
• FTLS – Formal Top Level Specification

Limitations
➢Criteria Creep
• Feature explosion in software products
➢Timeless of the Process
➢Focused on OS
• Security issues had expanded beyond operating systems by the 90’s

Federal Information Processing
Standards (FIPS)
➢Evaluation of cryptographic modules in order to ensure their quality
and security enforcement.
➢A cryptographic module is a set of hardware, firmware, or software,
or some combination thereof, that implements cryptographic logic or
processes.
➢FIPS 140-1 (1994 - 2002)
➢FIPS 140-2 (2002 - 2019)
➢FIPS 140-3 (2019 – still active)
➢https://csrc.nist.gov/publications/fips

FIPS - 2
➢Security Level 1: allows the software and firmware components of
a cryptographic module to be executed on a general purpose
computing system using an unevaluated operating system.
➢Security Level 2: allows the software and firmware components of
a cryptographic module to be executed on a general purpose
computing system using an operating system that is evaluated at
the CC evaluation assurance level EAL2. enhances the physical
security mechanisms of a Security Level 1 cryptographic module by
adding the requirement for tamper-evidence.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-
federal_standards_and_regulations

FIPS - 2
➢Security Level 3: In addition to detect, Crypto module should also
respond to attempts at physical access, use or modification of the
cryptographic module. The physical security mechanisms may
include the use of strong enclosures and tamper detection/response
circuitry that zeroizes all plaintext CSPs when the removable
covers/doors of the cryptographic module are opened. Ex: HSM.
• software and firmware components of a cryptographic module to be executed
on a general purpose computing system using an operating system that is
evaluated at the CC evaluation assurance level EAL3 (or higher)

FIPS - 2
➢Security Level 4: protects a cryptographic module against a
security compromise due to environmental conditions or
fluctuations outside of the module's normal operating ranges
for voltage and temperature. Intentional excursions beyond
the normal operating ranges may be used by an attacker to
thwart a cryptographic module's defenses. the software and
firmware components of a cryptographic module to be
executed on a general purpose computing system using an
operating system that is evaluated at the CC evaluation
assurance level EAL4.

1678784047-mid_sem-2.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a 1678784047-mid_sem-2.pdf

Similar a 1678784047-mid_sem-2.pdf (20)

Último

Último (20)

1678784047-mid_sem-2.pdf