Computer System Security

(040613601)

Lecture 12 :
Security Management, Plan, Risk
Assessment

By Assoc.Prof. Benchaphon Limthanmaphon, PhD.

 Objective
 Students be able to understand
 How important to build the Security Planning for an organization
 What advance preparation and study let us know that our
implementation meets our security needs for today and
tomorrow?
 Learn how to do the Risk analysis, vulnerability assessment and
penetrate test
 How do we weight the benefits of controls against their cost, and
how do we justify any controls?
 Understand Security Policy
 How do we establish a framework to see that our computer
security needs continue to be met?
 Raise the awareness of Physical control
 What aspects of the computing environment have an impact on
security?

2
 Contents
 Security Planning
 Business Continuity Plan
 Incident Response Plan
 Risk analysis
 Vulnerability Assessment
 Penetration Testing
 Security Policy
 Physical control
 Information Security Management System
 ISO 27001

3
 Think for a moment
 What good is a firewall if there is no power to run it?
 How effective is a public key infrastructure if someone can walk off
with the certificate server?
 Why have elaborate access control mechanisms if your employee
mails a sensitive document to a competitor?

 Keep in mind
Security is a combination of
 technical,
 administrative, and
 physical control.

4
 Security Planning
 A security plan is a document that describes how an organization will
address its security needs.
 It is subject to periodic review and revision as the organization’s security
needs change.
 A good security plan is an official record of current security practices, and a
blueprint for orderly change to improve those practices.
 By following the plan, developers and users can measure the effect of
proposed changes, leading eventually to further improvements.
 Moreover, a carefully written plan, supported by management, notifies
employees that security is important to management and therefore to
everyone.

 Thus, the security plan has to have the appropriate content and produce
the desired effects.

5
 Contents of a Security Plan
 A security plan identifies and organizes the security activities for a
computer system.
 It both describes the current situation and an improvement plan.
 Mostly address 7 issues:
 Policy - indicates goals of a computer security effort.
 Current state - describes the status of security at the time of the plan.
 Requirements - recommend ways to meet the security goals.
 Recommended controls - mapping controls to the vulnerabilities
identified in the policy and requirements
 Accountability - describe who is responsible for each security activity.
 Timetable - identify when different security functions are to be done.
 Continuing attention - specify a structure for periodically updating the
security plan

6
 Contents of a Security Plan (2)
1. Policy –A security policy is a high-level statement of purpose and intent.
Policy statement must answer 3 essential questions:
 Who should be allowed access?
 To what system and organizational resources should access be
allowed?
 What types of access should each user be allowed for each
resource?
 The policy statement should specify the following:
 The organization’s goals on security
 Where the responsibility for security lies
 The organization’s commitment to security – who provides
security support for staff, and where does security fit into the
organization’s structure?
2. Current state –To be able to plan for security, the organization must
understand the vulnerabilities to which it may be exposed, by performing
risk analysis. 7
 Contents of a Security Plan (3)
3. Requirements should have these characteristics:
 Correctness: Are the requirements understandable? Are they stated
without error?
 Consistency: Are there any conflict or ambiguous requirements?
 Completeness: Are all possible situations addressed by the
requirement?
 Realism: Is it possible to implement what the requirements
mandate?
 Need: Are the requirements unnecessarily restrictive?
 Verifiability: Can tests be written to demonstrate conclusively and
objectively that the requirements have been met?
 Traceability: Can each requirement be traced to the functions and
data related to it so that changes in a requirement can lead to easy
reevaluation?
Requirements may be constrained by budget, schedule, performance,
policies, governmental regulations, etc. 8
 Contents of a Security Plan (4)
4. Recommended controls
– the security plan must also recommend what control should be
incorporated into the system to meet the requirements.
5. Accountability
–The plan notes who is responsible for implementing controls when a new
vulnerability is discovered or a new kind of asset is introduced.

6. Timetable
–The plan should specify the order in
which the controls are to be
implemented so that the most serious
exposures are covered as soon as
possible.
7. Continuing attention
– the security plan must call for
reviewing the security situation
periodically. 9
 Security Planning Team Members
 The membership of a computer security planning team must
somehow relate to the different aspects of computer security:
 Security in OS and networks requires the cooperation of the
systems administration staff
 Program security measures can be understood and
recommended by applications programmers
 Physical security controls are implemented by the responsible for
general physical security, both against human attacks and natural
disasters.
 Finally, since controls affect system users, the plan should
incorporate users’ views, especially with regard to usability and the
general desirability of controls.

10
 Assuring Commitment to a Security Plan
 Commitment to the plan means that security functions will be
implemented and security activities carried out.
 3 groups of people must contributed to making the plan success:
 The planning team must be sensitive to the needs of each group
affected by the plan
 Those affected by the security recommendations must understand
what the plan means for the way they will use the system and perform
their business activities
 Management must be committed to using and enforcing the security
aspects of the system

 Some managers are not computing specialists e.g. Banking, medical.

The security plan must present security risks in language that managers
understand.
 It is important to avoid jargon and to educate the readers about the
nature of the perceived security risks in the context of the business the
system supports.
11
 Business Continuity Plan (BCP)
 Documents how a business will continue to function during a
computer security incident
 An ordinary security plan
 covers computer security during normal times and
 deals with protection against a wide rage of vulnerabilities from
the usual sources
 A business continuity plan deals with situations having 2
characteristics:
 Catastrophic situations – all or major part of a computing
capability is suddenly unavailable
 Long duration – the outage is expected to last for so long that
business will suffer.

12
Steps in Business Continuity Planning
 Assess Business Impact
 Focus on things that are critical to continued operation
 What are the essential assets
 what are the things that will prevent the business from doing
business
 what could disrupt use of these asset.
 Develop a strategy to control impact
 Investigate how the key assets can be safeguarded
 Must consider the time frame in which business is done
 Possible circumstance and evaluate alternatives
 Develop and implement a plan for the strategy
 Who is in charge
 What to do
 Who does it
13
 Incident Response Plans
 Tells how to deal with a security incident
 The goal is handling the current security incident, without regard for
the business issues
 An incident response plan should:
 Define what constitutes an incident
 Identify who is responsible for taking charge of the situation
 Describe the plan of action
 The plan normally has 3 phases:
 Advance planning
 Response Triage –considers: legal issues, preserving evidence,
records, and public relations
 Running the incident
 Is any security control action to be taken?
 Did the incident response plan work?
14
 Risk Analysis
 Is the process of examining a system and its operational context to
determine possible exposures and the potential harm they can
cause.
 Involves the identification and assessment of the levels of risk
 Calculated from the
 Values of assets
 Threats to the assets
 Their vulnerabilities and likelihood of exploitation

Assets Threats Vulnerabilities

Analysis
Risks

Management
Security Measures 15
 Terminologies
 Risk - a potential problem that the system or its users may
experience
 Threat – harm that can happen to an asset
 Risk impact – a measure of the seriousness of a threat or a loss
associated with an event.
 The event must generate a negative effect: compromised security,
lost time, diminished quality, lost money, lost control, lost
understanding. This loss is called the risk impact.
 Problem – certain occurrence risk probability or the likelihood that
the event will occur.
 Risk control – a set of actions to reduce or eliminate the risk
 Risk exposure – quantify the effects of a risk by multiplying the risk
impact by the risk probability
 Risk leverage – the difference in risk exposure divided by the cost of
reducing the risk
16
 Risk Analysis
 Goals of risk analysis:
 All assets have been identified
 All threats have been identified
 All vulnerabilities have been identified and assessed

 Strategies for risk reduction:

 Avoiding the risk – by changing requirements for security or other
system characteristics
 Transferring the risk – by allocating the risk to other systems ( eg.
Buying insurance to cover any financial loss)
 Assuming the risk – by accepting it, controlling it with available
resources, and preparing to deal with the loss if it occurs

17
 Problems of Measuring Risk
Businesses normally wish to measure in money, but many of the entities
do not allow this
 Valuation of assets
 Value of data and in-house software - no market value
 Value of goodwill and customer confidence
 Likelihood of threats
 How relevant is past data to the calculation of future probabilities?
 The nature of future attacks is unpredictable
 The actions of future attackers are unpredictable
 Measurement of benefit from security measures
 Problems with the difference of two approximate quantities
 How does an extra security measure affect a ~10-5 probability
of attack?

18
 Risk Analysis Steps

 Decide on scope of analysis

 Set the system boundary
 Identification of assets & business processes
 Determine vulnerabilities
 Estimate likelihood of exploitation
 Compute expected annual loss
 Survey applicable controls and their costs
 Project annual savings of control

19
 Risk Analysis – Defining the Scope
 Draw a context diagram
 Decide on the boundary
 It will rarely be the computer!
 Make explicit assumptions about the security of neighbouring domains

Risk Analysis - Identification of Assets

 Types of asset
 Hardware
 Software: purchased or developed programs
 Data
 People: who run the system
 Documentation: manuals, administrative procedures, etc
 Supplies: paper forms, magnetic media, printer liquid, etc
 Money
 Intangibles
 Goodwill
 Organisation confidence
 Organisation image 20
 Risk Analysis – Determine Vulnerabilities
 This step requires imagination.
 Predict what damage might occur to the assets and from what sources
 Identification and valuation of threats - for each group of assets
 Identify threats, e.g. for stored data
 Loss of confidentiality
 Loss of integrity
 Loss of completeness
 Loss of availability (Denial of Service)
 For many asset types, the only threat is loss of availability
 Assess impact of threat
 Assess in levels, e.g. H-M-L or 1 - 10
 This gives the valuation of the asset in the face of the threat

21
 Risk Analysis – Estimate Likelihood of
Exploitation
 Determine how often each exposure is likely to be exploited
 Likelihood of occurrence relates to the stringency of the existing controls
and the likelihood that someone or something will evade the existing
controls.
 We can try to apply frequency probability by using observed data for a
specific system
 Local failure rates are easy to record, we can identify which failures
resulted in security beaches or created new vulnerabilities
 Another alternative is to estimate the number of occurrences in a given
time period.
 Delphi approach is a subjective probability technique deal with public
policy decisions.
 Assumes that experts can make informed estimates based on their
experience
 The method brings a group of experts to consensus.

22
 Risk Analysis – Compute Expected Loss
 Determine the likely loss if the exploitation does indeed occur.
 Must analyze the ramifications of a computer security failure.
 Questions for thinking about issues of explicit and hidden cost related to
security are:
 What are the legal obligations for preserving the confidentiality or
integrity of a given data item?
 What business requirements and agreements cover the situation?
 Could release of a data item cause harm to a person or organization?
 Could unauthorized access to a data item cause loss of future business
opportunity?
 What is the psychological effect of lack of computer service?
 What is the value of access to data or program?
 What is the value to someone else of having access to data or
programs? How much would a competitor be willing to pay for access?
 What other problems would arise from loss of data? Could the data be
replaced or reconstructed? With what amount of work?
23
Risk Analysis – Survey & Select New Controls
 Match each vulnerability with at least one appropriate security
technique
 Example: Risk of losing data – could be addressed by several controls:
 Periodic backups, redundant data storage, access control to
prevent unauthorized deletion, physical security to keep someone
from stealing a disk, or program development to limit the effect of
programs on the data.

24
 Risk Analysis – Survey & Select New Controls
(2)

 What criteria are used for selecting controls?

 Use the list to mitigate the effects of a vulnerability
 How do controls affect what they control
 Controls have positive and negative effects
 Which controls are best?
 Need a way to determine the most appropriate controls for a given
situation.

25
 Risk Analysis – project savings
 Determine whether the costs outweigh the benefits of preventing or
mitigating the risks.
 Multiply the risk probability by the risk impact to determine the risk
exposure.

P(UO) = probability of
unwanted outcome
L(UO)= loss with
unwanted outcome

Risk Calculation for Regression Testing.

26
Risk Analysis Example
https://www.first.org/cvss/calculator/3.0

27
 Risk Analysis Example
https://nvd.nist.gov/vuln

28
 Arguments for and Against Risk Analysis
 Improve awareness  False sense of precision and
confidence
 Relate security mission to
management objectives  Hard to perform

 Identify assets, vulnerabilities,  Immutability

and controls
 Lack of accuracy
 Improve basis for decisions

 Justify expenditures for security

29
 Vulnerability Assessment and Penetration Testing

 two types of vulnerability testing

 focus on identifying vulnerability in the system
 two different tasks, with different results, within the same area of focus

 Vulnerability Assessment (VA)

 systematic method to find the security flaw in the system
 involve using automated testing tools such as web and network
security scanners
 Outcome for VA
 an assessment report listing all vulnerabilities, which categorised
based on severity.
 the report serves as a base for the penetration testing (PT)

30
 What is Vulnerability Assessment?
 A vulnerability assessment is the process of
 defining, identifying, classifying and prioritizing security
weaknesses and vulnerabilities in systems, including servers,
applications, and network infrastructures.
 It evaluates exposure of the system to known vulnerabilities and
assigns severity levels to those vulnerabilities, and recommends
remediation or mitigation, if and whenever needed.
 The main goal of vulnerability assessments is to provide the
necessary knowledge, awareness, and risk backgrounds to an
organization to take appropriate actions against threats to its
environment.

31
 Types of vulnerability Assessment
 Host based scan. Focus on critical services. This scan includes:
 Open ports in each server,
 Reviewing patching - updated
 Reviewing the security configuration – follows the best practices
 Network and Wireless Scan – focus on network security practices like
using DMZ, Firewall, separating the service and virtual machine.
 Wireless – focus on encryption, preventing of rouge access point
 The assessment of practices and configurations used to prevent
unauthorized access to networks and network-accessible resources
 Database Scan : looking for weak points in a database to prevent
malicious attacks
 look for vulnerabilities, misconfiguration, identify rough databases or
insecure dev/test environments.
 Application Scan: identify the vulnerabilities in web applications and their
source code and configuration.
32
 The Vulnerabilities Assessment Process
1. Vulnerability Identification (Testing)
 create a list of vulnerabilities identified in the systems by using
scanning tools.
 relate vulnerabilities to their threats. Example, unpatched windows
server.
2. Vulnerability Result Analysis.
 The objective of this step is to identify the source and root cause of
the vulnerabilities identified earlier.
 For example, the root cause of a vulnerability could be an old
version of software running on the server and this version cannot
work on the new server which create the vulnerabilities in our
organization systems. This provides a path for remediation.

33
 The Vulnerabilities Assessment Process
3. Risk Assessment
 prioritize the vulnerabilities, rank them, and assign a severity score
to each vulnerability, based on factors like:
 Which business functions are at risk.
 Which systems are affected.
 What data is at risk
 Ease of attack
 Potential damage as a result of the Vulnerability.
Impact

Low Medium High

Likelihood

High Medium risk(3) High risk (4) Highest risk (5)

Medium Low risk (2) Medium risk(3) High risk (4)
Low Lowest risk (1) Low risk (2) Medium risk(3)
34
The Vulnerabilities Assessment Process

4. Remediation
 In this step we specify the actions needed to be done to
remediate vulnerabilities that we found in the previous steps and
plan the execution of these actions
 Remediation Actions might be:
 Create security procedures
 The updating or change configurations of systems
 Apply new security systems like firewalls.

35
 Vulnerability Assessment and Penetration Testing

 Penetration Testing (PT)

 an attempts to actively exploit weaknesses in the system.
 A penetration testing requires various levels of expertise.
 more focus on real-life attack, testing and mapping paths a real hacker
can conduct.
 involves using automated vulnerability scanners and manual pen-test
tools

 Outcome for PT
 An evidence in the form of screenshot, which illustrates the finding and
remediation.

36
Type of Penetration Testing

37
 Type of Penetration Testing
 Black box model
 closest simulation to a real-life attack
 tester know nothing of the system
 consume most time and resources
 White box model
 tester has full knowledge and access to
resource
 consume least time to conduct
 most valuable information for the company
 Grey box model
 Hybrid of black and white models
 balance time and resource
 some access to system
 use broader test method to identify what may effect the system
38
 Vulnerability Assessment and Penetration Testing

Vulnerability scan Penetration test

At least quarterly, especially after Once or twice a year, as well as

new equipment is loaded or the anytime the Internet-facing equipment
Frequency
network undergoes significant undergoes significant changes
changes
Provide a comprehensive baseline of Concisely identify what data was
Reports what vulnerabilities exist and what compromised
changed since the last report
Lists known software vulnerabilities Discovers unknown and exploitable
Focus that could be exploited weaknesses in normal business
processes
Typically conducted by in-house staff Best to use an independent outside
Performed
using authenticated credentials; service and alternate between two or
by
does not require a high skill level three; requires a great deal of skill
Detects when equipment could be Identifies and reduces weaknesses
Value
compromised

39
 Vulnerability Assessment and Penetration Testing

 VA Tools
 Acunetix - Fully automated web vulnerability scanner
 Wireshark - Basically a network protocol analyzer
 Nmap - Network exploration and security auditing
 Nessus - IPs scanner, website scanner
 PT Tools
 Metasploit - Use for pentesting. It is based on the concept of ‘exploit’
 Kali Linux - Pentesting open source project
 Burpsuite - Mainly works with intercepting proxy, crawling content and
functionality, web application scanning
 John The Ripper - Password cracker
 Sqlmap - used for detecting and exploiting SQL injection issues
 Nmap - Predominantly aids in understanding the characteristics of
any target network
40
 Organizational Security Policies
 the security policy of a computer system is a high level specification
about the security to be achieved, not about the mechanism used to
achieve that security
 a security system is not a security system unless it attempts to
enforce compliance with the usage permissions of the items in the
computer system
 Thus a security policy could simply state that the security system
will enforce compliance with the usage permissions as defined by
owners of items in the computer system on the entities in the
system
 Other documents – procedures or guidelines – define how the
policy translates into specific actions and controls.

41
 Security Policy
 Purpose
 Recognizing sensitive information assets
 Clarifying security responsibilities
 Promoting awareness for existing employees
 Guiding new employees
 Audience
 Users – expect a certain degree of confidentiality, integrity, and
continuous availability in the computing resources.
 Owners – policy should reflect the expectations and needs of owners
 Beneficiaries – varying degree
 Contents
 Must identify its audience including the purpose of the computing
system, the resources needing protection, and the nature of the
protection to be supplied.

42
 Characteristics of a Good Security Policy
 Coverage
 A security policy must be comprehensive – must either apply to or
explicitly exclude all possible situation
 must be general enough to apply naturally to new cases that occur as
the system is used in unusual or unexpected ways
 Durability
 A security policy must grow and adapt well – expand without change
 However, the policy must be changeable when it needs to be – such as
when government regulations mandate new security constraints.
 Realism
 Must be beneficial in terms of time, cost, and convenience.
 The policy should not recommend a control that works but prevents the
system or its users from performing their activities and functions.
 Usefulness
 The policy must be written in language that can be read, understood,
and followed by anyone who must implement it or is affected by it. 43
 Physical Security
 Also called infrastructure security.
 Protects the information systems that contain data and the people who
use, operate, and maintain the systems.
 Physical security also must prevent any type of physical access or
intrusion that can compromise logical security.
 The role of physical security is to protect the physical assets that support
the storage and processing of information.
 Physical security involves two complementary requirements.
 physical security must prevent damage to the physical infrastructure
that sustains the information system.
 physical security must prevent misuse of the physical infrastructure
that leads to the misuse or damage of the protected information.
 The misuse of the physical infrastructure can be accidental or
malicious.
 It includes vandalism, theft of equipment, theft by copying, theft of
services, and unauthorized entry.
44
 Physical Security Threats
 physical situations and occurrences that threaten information systems:
 environmental threats
 technical threats
 human-caused threats
 Environmental Threats (Natural Disasters)
 are the source of a wide range of environmental threats to data
centers, other information processing facilities, and their personnel.
 Computer are subject to the same natural disasters that can occur to
homes, stores, and automobiles.
 Can be flooded, burned, melted, hit by falling objects, and destroyed by
earthquakes, storms, and tornadoes.
 It is impossible to prevent natural disasters, but through careful
planning it is possible to reduce the damage they inflict.

45
 Physical Security Threats (2)
 Technical threats
 related to electrical power and electromagnetic emission.
 electrical power is essential to run equipment
 power utility problems:
 under-voltage - dips/brownouts/outages, interrupts service
 over-voltage - surges/faults/lightening, can destroy chips
 noise - on power lines, may interfere with device operation
 electromagnetic interference (EMI)
 noise along a power supply line, motors, fans, heavy equipment,
other computers, cell phones, microwave relay antennas, nearby
radio stations
 noise can be transmitted through space as well as through power
lines
 can cause intermittent problems with computers

46
 Physical Security Threats (3)
 Human-caused threats (Human Vandals)
 less predictable, designed to overcome prevention measures, harder to
deal with
 include:
 unauthorized physical access
 information assets are generally located in restricted areas
 can lead to other threats such as theft, vandalism or misuse
 theft of equipment / data
 eavesdropping and wiretapping fall into this category
 insider or an outsider who has gained unauthorized access
 vandalism of equipment / data
 misuse of resources

47
Physical Security Prevention and Mitigation Measures

 one prevention measure is the use of cloud computing

 inappropriate temperature and humidity
 environmental control equipment, power supply
 fire and smoke
 alarms, preventative measures, fire mitigation
 smoke detectors, no smoking
 water
 manage lines, equipment location, cutoff sensors
 other threats
 appropriate technical counter-measures, limit dust entry, pest
control

48
 Mitigation Measures Technical Threats
 To deal with brief power interruptions, an uninterruptible power supply
(UPS) should be employed for each piece of critical equipment.
 UPS units can also function as surge protectors,
power noise filters, and automatic shutdown devices when
the battery runs low.
 For longer blackouts or brownouts, critical equipment should be
connected to an emergency power source, such as a generator.
 For reliable service, a range of issues need to be addressed by
management, including product selection, generator placement,
personnel training, testing and maintenance schedules, and so
forth.
 To deal with electromagnetic interference, a combination of filters and
shielding can be used.
 The specific technical details will depend on the infrastructure
design and the anticipated sources and nature of the interference.
49
 Mitigation Measures Human-Caused Threats

 physical access control

 restrict building access
 controlled areas patrolled or guarded
 locks or screening measures at entry points
 equip movable resources with a tracking device
 power switch controlled by a security device
 intruder sensors and alarms
 surveillance systems that provide recording and real-time remote
viewing

50
Recovery from Physical Security Breaches

 most essential element of recovery is redundancy

 provides for recovery from loss of data
 ideally all important data should be available off-site and updated
as often as feasible
 can use batch encrypted remote backup
 for critical situations a remote hot-site that is ready to take over
operation instantly can be created
 physical equipment damage recovery
 depends on nature of damage and cleanup
 may need disaster recovery specialists

51
 ISMS – Information Security Management System
BS7799 Part 1 is now ISO/IEC 17799:2000
Incorporates good security practice, with 127 security guidelines
(which can be drilled down to provide over 600 other controls)
BS7799 Part 2
A framework for an ISMS – information security management
system, which is the means by which Senior Management monitor
and control their security, minimize risk and ensures compliance

52
 ISMF - 1.Risk Management, Vulnerability
Assessment and Penetration Testing
 Risk and vulnerability assessment for ICT
 Vulnerability Assessment (VA)
 systematic method to find the security flaw in the system
 Penetration Testing by using Ethical Hacking
 attempts to actively exploit weaknesses in the system
 Target: sensitive data ex. Username, Password
 Black-Box Penetration Testing
 DoS Attack
 Target: Web server, IP Address
 White-Box Penetrate Testing
 Intranet risk assessment
 Tester on side (login LAN)
 Grey box Penetration Testing
 Hybrid of black and white models
 balance time and resource
53
 ISMF - 2. Critical Network & Hosts Hardening /
Patching / Fixing

 Server or Host hardening

 Close un-used service ports on server
 ex. Web server 80 (http), 443 (https)
 Set up firewall
 Rules
 Bastion host
 Patch or Hotfix update

54
 ISMF – 3.Practical Information Security Policy

 Need organization security policy

 Safe Internet usage
 Against: virus, trojan horse, user mistake, social engineering
 Mechanisms only - inadequate
 Need administrative level Access Control Layers
 Policy
 Standard
 Guideline
 Procedure

55
ISMF – 3.Practical Information Security Policy (2)
 Policy like a strategic plan because they outline what should be done
but don’t specifically dictate how to accomplish the stated goals.
 Standards are tactical documents because they lay out specific steps
or processes required to meet a certain requirement.

 A guideline points to a statement in a policy or

procedure by which to determine a course of
action. It’s a recommendation or suggestion of
how things should be done. It is meant to be
flexible so it can be customized for individual
situations.

 Procedures step-by-step approach

toward implementing security
standards and guidelines that support
the policies. Procedures will likewise
differ between organizations.
56
 ISMF – 4. Defense-In-Depth/ Best Pratices
Implementation
 Defense in depth is the coordinated use of multiple security
countermeasures to protect the integrity of the information assets in an
enterprise.
 The strategy is based on the military principle that it is more difficult for an
enemy to defeat a complex and multi-layered defense system than to
penetrate a single barrier.
 Organization is divided so called “Compartmentalization
 Defense in depth concerned:
 Re-Design Network Perimeter Architecture
 In-Depth Host and Network Devices Hardening
 Change Management / Log Monitoring
 Securing Your Database and Web Application
 Thinking on Business Continuity Planning / Disaster Recovery Planning

57
 ISMF – 5. Security Awareness /
Technical Know-how Transfer Training

 People without awareness is a majority threat to computer system

 Security awareness training is required for vary levels/groups

 Executive, middle rank managers, end users

 System admin, security admin or IT auditors need more

 Ex. Security incident case study, How hacker work, virus

 Counter measures

58
 ISMF – 6. Internal / External Audit
Re-Assessment and Re-Hardening
 IT Auditor should have Compliance Check-list for system assessment
 Target: gap analysis, compliant to IT security policy, proper best
practices
 Information system audit must considered “controls” compose of
 Preventive Control
 Detective Control
 Corrective Control
 IT Auditor must consider in three perspective:
 Administrative Control
 Technical Control
 Physical Control

59
 ISMF – 7. Managed Security Services (MSS) /
Real-time Monitoring using IDS/IPS
 Monitor log analysis is timely work and need expert to differentiate between
fault alarm or real attack alarm
 Expert – intrusion analysis
 Need “outsource” to manage security service
 Risk management and risk mitigation
 Managing and monitoring
 Network perimeter security
 External firewall, border router, IDS/IPS, VPN, Servers in DMZ
 Vulnerability assessment continuity
 Security breach incident consultant
 Centralized log /patch systematically management
 Inform information security news especially – new vulnerability / exploit,
new virus

60
 ISO Security Product
 ISO/IEC 27001 – Information Security Management System (ISMS)
 27000 Family of Standards
 ISO/IEC 18033 – Encryption Algorithms
 specifies asymmetric ciphers and symmetric ciphers
 ISO/IEC 7811 – Identification Cards
 ISO/IEC 2382-37 – Vocabulary
 Harmonized vocabulary for biometrics
 ISO/IEC 29100 – Privacy Framework
 Identifies privacy principles
 ISO/IEC 29134 – Privacy impact assessment
 ISO/IEC 29115 - Entity authentication assurance framework

61
 ISO 27001 or ISO/IEC 27001
 ISO 27001 is the International standard that provides guidelines for
safeguarding an organization’s asset
 helps organizations become risk-aware and proactively identify and
address weaknesses.
 promotes a holistic approach to information security: vetting people, policies
and technology.

 ISO 27001:2005 was the first standard dedicated to Information Security

 ISO 27001:2013 was published on the 25th September 2013 and it
replaced ISO 27001:2005
 ISO 27001:2022 replaces ISO 27001:2013 which had been technically
revised and updated – on October 25, 2022
 Comprehensive set of Clauses and Controls comprising best practices in
information security
 A framework for building a risk based security management system

62
 ISO 27001 Overview
 An information security management system implemented according to this
standard is a tool for risk management, cyber-resilience and operational
excellence.
 The design and implementation of an organization’s ISMS is influenced by
 its business and security objectives
 Its security risks and control requirements
 The processes employed
 The size and structure of the organization
 ISO 27001 consists of two main parts:
 the core requirements or framework of an ISMS (Clauses 4–10)
 a list of information security controls from which organizations may select
and implement to respond to the specific risks they face (Annex A)

63
 ISO 27001 clauses and controls
 ISO 27001:2022 has ten management system clauses. Together with
Annex A, which lists the 93 information security controls from ISO
27002:2022, they support the implementation and maintenance of an
ISMS.
 Scope  Planning
 Normative references  Support
 Terms and definitions  Operation
 Context of the organization  Performance evaluation
 Leadership  Improvement
 The 93 controls are grouped into four themes:
 Organisational (37 controls)
 People (8 controls)
 Physical (14 controls)
 Technological (34 controls)
64
 Annex A controls of ISO 27001:2022

Organisational (37 controls)

 Organisational controls focus on the policies, procedures, responsibilities
and other organisational-level measures necessary for effective
information security.
 They include:
 The information security policy and other core policies;
 Defined responsibilities for management and the people responsible
for operating the ISMS day to day;
 Contact with authorities and other relevant groups;
 Threat intelligence and monitoring;
 Classifying and labelling information;
 Identity and access control; and
 Asset management.

65
 Annex A controls of ISO 27001:2022

People (8 controls)
 People, particularly employees, are a critical part of the information
security equation.
 The controls include:
 Pre-employment screening;
 Staff awareness and training;
 Contracts and NDAs (non-disclosure agreements);
 Remote working; and
 Reporting security events.

66
 Annex A controls of ISO 27001:2022

Physical (14 controls)

 Physical controls focus on the physical environment of the ISMS. This
is every bit as important as the digital environment for ensuring
information security.
 The controls relate to, among other things:
 Security perimeters and secure areas;
 Clear desks and screens;
 Supporting utilities;
 Secure cabling; and
 Equipment maintenance.

67
 Annex A controls of ISO 27001:2022

Technological (34 controls)

 Technological controls are what most people think of when they think
about information security.
 The controls include:
 Malware protection;
 Backups;
 Logging and monitoring;
 Network security and segregation; and
 Development and coding practices.

68
 ISO 27002
 ISO 27002 is a complementary document to the ISO 27001 standard,
serving as an implementation guide for ISO 27001.
 ISO 27002 provides a thorough explanation for each of the controls
listed in Annex A, when it should be implemented, and instructions on
how to best implement it.

Certification vs. guidance

 The biggest difference between ISO 27001 and ISO 27002 is the
purpose of each document.
 The goal of ISO 27001 is certification — it provides criteria your ISMS
needs to meet to get compliant and pass your audit.
 The goal of ISO 27002 is to guide your implementation of ISO 27001.
There is no ISO 27002 certification.

69
 Certification to ISO/IEC 27001
 Compliance with ISO 27001 can be formally assessed and certified.
 A certified ISMS builds confidence in the organization’s approach to
information security management among stakeholders
 one way to demonstrate to stakeholders and customers that you
are committed and able to manage information securely and safely
 ISO 27001 Certification: 10 Easy Steps
1. Prepare - Get an understanding of ISO 2700
2. Establish the context, scope, and objectives
3. Establish a management framework. - describes the processes an organization
needs to follow to meet its ISO27001 implementation objectives.
4. Conduct a risk assessment
5. Implement controls to mitigate risks
6. Conduct training - staff awareness
7. Review and update the required documentation - support the necessary ISMS
processes, policies, and procedures.
8. Measure, monitor, and review
9. Conduct an internal audit
10. Registration/certification audits
Src: https://www.itgovernanceusa.com/blog/iso-27001-registrationcertification-in-ten-easy-steps 70