Information Security Assurance

‘Information Security Assurance – Why, What and How?’

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – Why is it an issue?

Because, if the information asset is not

suitably protected, it can be
¾given away or stolen without depriving you
of it
¾modified without your knowledge to make
it worthless
¾lost without trace or hope of recovery

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – Why is it an issue?
Because…..although the threats inIncyber space
a physical world one
remain by and large the same as in the out
success physical world
of 10000 attempts
Internet
would allows action
be ineffective. at a as
Where
(ex. fraud, theft and terrorism), they arecomputing
distance.
today’s different
Every point
power due
on the
and
Internet allows easier and
net is adjacent
bandwidth enablestothe
every other
same
to 3 important developments more rapid technique
point. Attacks are now
attack with stunning success
propagation, in a matter of
¾ automation has made attacks more profitable possible on distant hosts
hours or days. This means, it
anywhere in the world
is now more difficult to
¾ action at a distance is now possible
develop effective counter
measures in a timely fashion.
¾ attack technique propagation is now more rapid and
Hence we need to be secure
easier and proactive

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – Why is the reluctance?
¾ May be, the stakeholders including customers have
not yet started insisting on an assurance
¾ Many organisations would not want to implement
strong security measures thinking that they do not
have anything that others would want – probably
what they do not realize is that they could become
launch pads for attacks on others (Need to be good
neighbors)
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – Why is the reluctance?

¾ Quite possibly, there could be other pressing issues of

survival that relegate security to an afterthought
¾ Besides this, there is a very difficult choice between
convenience and security measure
¾ Or simply, their cyber space is empty

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – General trends

If you are not into it yet, you are not alone.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – General trends

Fortune 1,000 firms are spending less on security than

they spend on coffee and soft drinks.

Forrester Research, Inc.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – General trends

¾ If you think the greatest threat to information security

comes from outside- competitors, hackers or viruses
- think again (Large majority of the security problems
are attributed to insiders)
¾ These external threats will only distract from the
dangers you face from inside your own organization.

“Amateurs hack machines, professionals hack people”

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – General trends

¾Of course, if you are part of critical

information infrastructure, there could be
someone who is determined to get you for
obvious reasons.
¾The need is to have not only preventive
abilities, but also keep a track of adversaries
capabilities with changing times
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – General trends

SANS Security alert says

‘A few software vulnerabilities account for the

majority of successful attacks because attackers
don’t like to do extra work. They exploit the
best-known flaws with the most effective and
widely available attack tools. And they count on
organisations not fixing the problems in time’

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Result ?????
Uncertainty over issues such as
¾Availability
9 Is information accessible wherever and whenever
required
¾Integrity
9 Is information sufficiently right for the purpose at the
time of use
¾Confidentiality
9 Is information available only to those who are
authorised to access it

This is likely to result in lower trust levels

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security – General trends

It is certainly not true that organisations

are not interested in security.

…….Then what is holding them back?

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 What is the problem?

“To determine how much is too much, so that we can

implement appropriate security measures to build
adequate confidence and trust”

“We want a powerful logic for implementing or not

implementing a security measure”

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 What is needed?
There are three important questions that organisations must
answer when addressing security considerations of their
information and information systems:
¾ Selection of security controls (is it adequate?)
¾ Implementation of security controls (is it effective?) and
¾ Assurance of security controls (does it work?)
“The answers to these questions cannot be given in isolation.
They must be given in the context of an Information Security
program for the organisation that identifies, controls and
mitigates risks to its information and information systems.”

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 What is needed?

Management concerns
Market reputation
Security measures
Business continuity
Technical
Disaster recovery
Procedural
Business loss Information Security Physical
Program
Loss of confidential
Logical
data
Personnel
Loss of customer
confidence Management
Legal liability
Cost of security

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security Program or Management

This would invariably mean

¾ a top driven approach with full management
involvement and commitment
¾ clear identification and allocation of security related
responsibilities
¾ Security policies, procedures and plans
¾ periodic test/evaluation, assessments & reviews
¾ security awareness and compliance
¾ vigilant attitude and proactive improvements
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 What is a Management System?

It represents a
Structure blend of enablers &
deterrents

Achievement of
Resources organisation’s policies and Procedures
objectives

Processes

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Management Systems

S tra teg y

M a n a g e m e n t S y ste m s

S tr u c tu r e
Human Resource

Health & Safety

Information

Environment
Financial

P o lic y /p r o c e d u r e

Quality
P ro c e ss

R eso u rces

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Management Systems
Provide Assurance
S tr a te g y through discipline of
compliance
M a n a g e m e n t S y s te m s

S tr u c tu r e
Human Resource

Health & Safety

Information

Environment
Financial

P o lic y /p r o c e d u r e

Quality P ro cess

R eso u rces

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Managing Risks
Management of risks is central to business
and comfort levels.
Risks are managed through
¾prudent business practices
¾careful contracting
¾use of appropriate control mechanisms and
¾insurance
We need to progressively increase the comfort
levels

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 How do we increase the comfort level?
Information
Security Assurance
Comfort level

Security
Management Penetration testing &
Red team exercises
system vulnerability analysis
assessment

• High level overview of security • Builds on the management • This is the most resource
posture with base level system assessment intensive service, but provides
comfort factor • Although more resource the most realistic analysis of
• Since no hands-on testing is intensive, provides a higher security posture
involved, requires minimum level of assurance • Involves estimation of
use of time and assessor • Needs cooperation of system adversary capabilities and no-
resources administrators notice attack on the system
• Provides an idea of the • Includes use of tools • Can be performed at various
potential vulnerabilities • The output enables higher intensities as per pre-
• Provides a basis for testing degree of protection and determined ‘Rules of
and Red team exercises comfort factor Engagement’

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Object of Information Security Assurance
Such as
•Fireof
Security assurance aims at
In terms ensuring
•Denial of service
•Deterrence
In terms of •Malicious code
System’s ability •Protection
•Confidentiality
•Malicious destruction of
•Detection
•Integrity data and
•Response andfacilities
to provide •Availability •Masquerade
•Recovery capabilities
•Accountability
•Theft and fraud
Assurance on asset characteristics
•Authenticity and
•Web-site intrusion
•Reliability •Failure of communication
from services
•Loss of key personnel

Perceived threats •Operational staff or user

error

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Which includes
Information Security Assurance - Perspectives
•Security policy and
review
In•Information
Interms
termsofof
security
infrastructure
•PDCA
In terms of approach
•BCP management
•Security of third and
party
¾Management perspective •Risk
•Compliance assessment
process
access
management
with
applicable legislation
•Business impact
•Asset
and copyclassification
•IPR•Documentation right and
¾Protection perspective analysis
and control
records
protection
•BCP plans and
•Personnel
•Reviews,
•Safeguarding security
audits
records and
implementation
¾Continuity perspective •Physical
continual
•Privacy and
improvement
and data
•Testing and re-
environmental security
protection
assessment of BCP
¾Legal perspective •Networks
•Prevention and
plans of misuse of IT
Communications
•Regulation of
management
cryptographic controls
•Legal•Access control
admissibility of
•Software development
evidence
CERT-In and maintenance
September 3, 2004
Department of Information Technology
We Assure
 What is good Security Assurance?

Prevention Threat
Reduction
Detection
Incident
Repression
Damage
Correction

Recovery
Evaluation

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Security Assurance actions - Emphasis

With security assurance we are not intending to make the

system ‘hacker proof’, but devise a mechanism which can, to
a large extent
™ Anticipate potential problems
™ Pre-empt through proactive measures
™ Protect against considerable damages
™ Ensure recovery and restoration

‘It is all about the ability to expect the expected before we are
ready to expect the unexpected’

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security Assurance Program

Policies and Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Security Policies – Why use them ?

• Without security policies, you have no general security

framework.
• Policies define what behavior is and is not allowed.
• Policies will often set the stage in terms of what tools
and procedures are needed for the organization.
• Policies communicate consensus among a group of
“governing” people.
• Computer security is now a global issue and computing
sites are expected to follow the “good neighbor”
philosophy.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Who and what to trust?

¾ Trust is a major principle underlying the development of

security policies.
¾ Initial step is to determine who gets access.
– use principle of least access
¾ Deciding on level of trust is a delicate balancing act.
– too much -> eventual security problems
– too little -> difficult to find and keep satisfied employees
¾ How much should you trust resources?
¾ How much should you trust people?

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Possible Trust Models
¾ Trust everyone all the time
– easiest to enforce, but impractical
– one bad apple can ruin the whole barrel
¾ Trust no one at no time
– most restrictive, but also impractical
– impossible to find employees to work under such
conditions
¾ Trust some people some of the time
– exercise caution in amount of trust placed in employees
– access is given out as needed
– technical controls are needed to ensure trust is not
violated
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Why the political turmoil?

¾ People view policies as:

– an impediment to productivity
– measures to control behavior
¾ People have different views about the need for security
controls.
¾ People fear policies will be difficult to follow and implement.
¾ Policies affect everyone within the organization
– most people resist measures which impede productivity
– some people strongly resist change
– some people strongly resist the “big brother syndrome”
– some people just like to “rock the boat”

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Who should be concerned?

¾Users - policies will affect them the most.

¾System support personnel - they will be
required to implement and support the
policies.
¾Managers - concerned about protection of
data and the associated cost of the policy.
¾Business lawyers and auditors - are
concerned about company reputation,
responsibility to clients/customers.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 The Policy Design Process

¾Choose a policy development team.

¾Designate a person or “body” to serve as
the official policy interpreter.
¾Decide on the scope and goals of the
policy.
– scope should be a statement about who is covered by
the policy.
¾Decide on how specific to make the policy
– not a detailed implementation plan
– don’t include facts which change frequently

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 The Policy Design Process

¾ All people affected by the policy should be

provided an opportunity to review and comment
on the policy before it becomes official.
– very unrealistic for large organizations
– often difficult to get the information out and ensure people read it.

¾ Incorporate policy awareness as a part of

employee orientation.
¾ Provide refresher overview course on policies
once or twice a year.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Basic Requirements
¾ Policies must:
– be implementable and enforceable
– be concise and easy to understand
– balance protection with productivity
– be updated regularly to reflect the evolution of the
organization
¾ Policies should:
– state reasons why policy is needed
– describe what is covered by the policies - whom, what,
and where
– define contacts and responsibilities to outside agencies
– discuss how violations will be handled
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Determining Level of Control

¾ Security needs and culture play major role.

¾ Security policies MUST balance level of control
with level of productivity.
¾ If policies are too restrictive, people will find
ways to circumvent controls.
¾ Technical controls are not always possible.
¾ Must have management commitment on level
of control.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Choosing A Policy Structure
¾ Dependent on company size and goals.
¾ One large document or several small ones?
– smaller documents are easier to maintain and update
¾ Some policies appropriate for every site,
others are specific to certain environments.
¾ Some key policies:
– Acceptable Use
– User Account
– Remote Access
– Information Protection etc.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 The Acceptable Use Policy

¾Discusses and defines the appropriate use

of the computing resources.
¾Users should be required to read and sign
AU policy as part of the account request
process.
¾Many examples of AU policies can be found
on:
– http://www.eff.org/pub/CAF/policies/

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Element of Acceptable Use Policy

¾ Should state responsibility of users in terms of

protecting information stored on their accounts.
¾ Should state if users can read and copy files that
are not their own, but are accessible to them.
¾ Should state if users can modify files that are not
their own, but for which they have write access.
¾ Should state if users can share accounts.
¾ Should state if users can make copies of
copyrighted software?
¾ Should state level of acceptable usage for
electronic mail and Internet access.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 User Account Policy

¾ Outlines the requirements for requesting and

maintaining an account on the systems.
¾ Very important for large sites where users
typically have accounts on many systems.
¾ Some sites have users read and sign an Account
Policy as part of the account request process.
¾ Example User Account Policies are also available
on the CAF archive along with the Acceptable
Use Policies.
– http://www.eff.org/pub/CAF/policies/

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Elements of a User Account Policy

¾ Should state who has the authority to approve

account requests.
¾ Should state who is allowed to use the
resources (e.g., employees or students only)
¾ Should state if users are allowed to share
accounts or if users are allowed to have
multiple accounts on a single host.
¾ Should state the users’ rights and
responsibilities.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Elements of user Account Policy

¾Should state when the account should be

disabled and archived.
¾Should state how long the account can
remain inactive before it is disabled.
¾Should state password construction and
expiration rules.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Remote Access Policy
¾ Outlines and defines acceptable methods of
remotely connecting to the internal network.
¾ Essential in large organization where networks
are geographically dispersed and even extend
into the homes.
¾ Should cover all methods chosen to remotely
access internal resources. Example:
– dial-in (SLIP, PPP)
– ISDN/Frame Relay
– telnet access from Internet
– Cable modem
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Element of Remote Access Policy
¾ Should define who is allowed to have remote
access capabilities.
¾ Should define what methods are allowed for
remote access.
¾ Should discuss if dial-out modems are allowed.
¾ Should discuss who is allowed to have high-
speed remote access such as ISDN, Frame
Relay or cable modem.
– what extra requirements are there?
– can other members of household use network? etc.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Elements of Remote Access Policy

¾Should discuss any restrictions on data that

can be accessed remotely.
¾If partners connections are commonplace,
should discuss requirements and methods.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Protection Policy

¾Provides guidelines to users on the

processing, storage and transmission of
sensitive information.
¾Main goal is to ensure information is
appropriately protected from modification or
disclosure.
¾May be appropriate to have new employees
sign policy as part of their initial orientation.
¾Should define sensitivity levels of
information.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
Key Elements of Information Protection Policy
¾ Should define who can have access to sensitive
information.
– special circumstances
– non-disclosure agreements
¾ Should define how sensitive information is to be stored
and transmitted (encrypted etc).
¾ Should define on which systems sensitive information can
be stored.
¾ Should discuss what levels of sensitive information can be
printed on physically insecure printers.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
Key Elements of Information Protection Policy

¾Should define how sensitive information is

removed from systems and storage
devices.
– degaussing of storage media
– scrubbing of hard drives
– shredding of hardcopy output
¾Should discuss any default file and directory
permissions defined in system-wide
configuration files.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Sample E-mail Policy
¾ The company maintains a voice mail and an e-mail system
to assist in the conduct of business within the company.
These systems, including the equipment and the data
stored in the system, are and remain at all times the
property of the company. As such, all messages created,
sent, received, or stored in the system are and remain the
property of the company
¾ Messages should be limited to conduct of business at the
company. Voice-mail and e-mail may not be used for the
conduct of personal business.
¾ The company reserves the right to retrieve and review any
message composed, sent, or received. Messages may be
reviewed by someone other than the intended recipient.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Sample E-mail Policy
¾ Messages may not contain content that may
reasonably be considered offensive or
disruptive to any employee. Offensive content
¾ Would include, but would not be limited to,
sexual comments or images, racial slurs,
gender-specific comments, or any comments
that would offend someone on the basis of his
or her age, sexual orientation, religious or
political beliefs, national origin, or disability.
¾ Employees learning of any misuse of the v-mail
or e-mail system or violations of this policy shall
notify the Director of HRD.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Policies and Procedures

¾Trust Models
¾Security Policy Basics
¾Policy Design Process
¾Key Security Policies
¾Key Security Procedures

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Security Procedure
¾ Policies only define "what" is to be protected.
Procedures define "how" to protect resources and
"what" are the mechanisms to enforce policy.
¾ Procedures define detailed actions to take for
specific incidents.
¾ Procedures provide a quick reference in times of
crisis.
¾ Procedures help eliminate the problem of a single
point of failure (e.g., an employee suddenly
leaves or is unavailable in a time of crisis).

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Configuration Management Procedure

¾Defines how new hardware/software is

tested and installed.
¾Defines how hardware/software changes
are documented.
¾Defines who must be informed when
hardware and software changes occur.
¾Defines who has authority to make
hardware and software configuration
changes.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
Data Backup and Off-site Storage Procedures

¾Defines which file systems are backed up.

¾Defines how often backups are performed.
¾Defines how often storage media is rotated.
¾Defines how often backups are stored off-
site.
¾Defines how storage media is labeled and
documented.
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Security Incident Escalation Procedure

¾A "cookbook" procedure for frontline

support personnel.
¾Defines who to call and when.
¾Defines initial steps to take.
¾Defines initial information to record.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Incident Handling Procedure
¾ Defines how to handle intruder attacks.
¾ Defines areas of responsibilities for members of
the response team.
¾ Defines what information to record and track.
¾ Defines who to notify and when.
¾ Defines who can release information and the
procedure for releasing the information.
¾ Defines how a follow-up analysis should be
performed and who will participate.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Disaster Planning and Response

¾ A disaster is a large scale event which affects

major portions of an organization.
– a major earthquake, flood, hurricane, or tornado
– a major power outage lasting > 48 hours
– destruction of building structures
¾ Main goal of plan is to outline tasks to keep critical
resources running and to minimize impact of
disaster.
¾ Ensure critical information needed for disaster
response is kept off-site and easily accessible
after the onset of a disaster.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Disaster Planning and Response

¾Plan should outline several operating

modes based on level of damage to
resources.
¾Determine the need for “hot” or “cold” sites.
¾Disaster preparedness drills should be
conducted several times a year.

CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security - Final Message

“In security matters

Past is no guarantee; Present imperfect and
Future uncertain“
“Failure is not when you fall down, but when
you fail to get up”
CERT-In
September 3, 2004
Department of Information Technology
We Assure
 Information Security Assurance

Thank you

CERT-In
September 3, 2004
Department of Information Technology
We Assure